Installed sample project's "Data" / content files show up in VS
See original GitHub issueSummary
Just tested the new v4-alpha2 Duality project template and installed the Tilemaps sample package into the GameEditor
project. Everything worked as expected, but there is one issue that might easily throw off new users and could also annoy experienced users:
All the installed content files actually show up in the project in Visual Studio, and they can be edited via double-click. That alone would be tolerable, but any changes made are simply ignored and don’t end up in the actual project.
There are a lot of internal theories on how Duality works that new users might develop based on that, most of which would lead them into the wrong direction, so I’m flagging this as a usability bug. If possible, we should fix that in some way before the actual release.
Analysis
Here’s a number of ways this could be fixed, though I don’t really know how difficult any of them would be - @Barsonax probably has a better idea on that topic.
- Hide the content files completely, so they don’t show up in the VS project.
- Keep the content files read-only.
- Make sure any changes made to the content files end up in their copy in the actual project.
The last one is probably a bad idea, since that would mean letting users edit the content files in their local package cache directory. I’d probably go with the first option to avoid any potential confusion in the first place, if there is a way to achieve that.
Issue Analytics
- State:
- Created 3 years ago
- Comments:10 (10 by maintainers)
Top GitHub Comments
I think this is more a issue with visual studio handling of contentfiles in the solution explorer. Microsoft has chosen to dump everything in the root which is not very clear. It would be much clearer if it was listed under Dependencies under the respective package.
So I think we should make a issue about this (not sure which repo houses visual studio related issues) but until then we have to live with this.
EDIT: its still a open issue https://github.com/NuGet/Home/issues/4856
Alternatively, if the readonly fix is out there reasonably fast, that would be okay as well. As long as users can’t edit these files, they’ll get the idea that this is just something “for reference” and hopefully ignore them. Putting the file links into a subfolder named after the package like you did in the earlier experiment would also improve this.