Contentfiles pollute the root of the project

[Barsonax]

Visual Studio Version: 2019, seems to happen with all versions I have used so far up to 16.6.1

Summary:
Currently contenfiles seem to just get dumped in the root of the project in the solution explorer:

This is very confusing behavior as its not clear where these files are coming from. In our usecase we use contentfiles to deliver some resource files such as textures in our sample packages for our game engine. We would prefer to not show all these files. I saw you can solve it partially with hacks like these:

    <None Update="@(None)">
      <Visible>false</Visible>
    </None>

But you still end up with empty folders appearing.

Steps to Reproduce:

1. Add a nuget package with contenfiles to the solution (for instance our AdamsLair.Duality.Samples.Tilemaps 4.0.0-alpha2 package)

2. See all the contenfiles appear in the solution explorer

Expected Behavior:
Show these files in Dependencies/Packages/Packageid. Alternatively make it possible to hide these files by adding a attribute to the nuspec file and csproj.

Actual Behavior:
All contenfiles are visible in the root of the project in the solution explorer

User Impact:
Very confusing for users, on top of that these files are editable which they shouldn't be and this leads to nasty bugs. This was already reported in #2141 though but is still not fixed.

Contentfiles have been around for a while now but the bugs in the tooling don't seem to get fixed. Whats the holdup? This is not production ready like this. Are there any major blockers to fix this?

[jjmew]

Showing the files in the tree is by design. However they shouldn't be editable. We have bumped the priority of #2141

[Barsonax]

Wow this is just getting closed because its by design???? @jjmew

I believe just putting these files in the root of the project is very confusing. Theres no way to change this. Even with some csproj hacking the best you can do is having some empty folders.

Iam not the only one bothered by this NuGet/Home#4856. If this is the design then its a pretty bad one.

[davkean]

Please remember to keep comments respectful, we're humans over here.

Showing files from imports is very much by design, it's fundamental to SDK-based projects. Without it, you would have zero files listed in a project by default as the default set of globs come from imports.

Package authors should be using <Visible>false</Visible> on these content files if they are not intended to be shown in the project, I'll continue to let NUGet track adding a feature to control this via NuGet/Home#4856.

As for the folders still being visible, this is owned by an external team to this respository and was being tracked by https://developercommunity.visualstudio.com/content/problem/495189/parent-folder-of-items-marked-as-visiblefalse-stil.html. It was closed as lower priority but I've converted it to a product Suggestion, and reopened it so you can vote it on. It might take a while to reflect on the Developer Community side.

[Barsonax]

Please remember to keep comments respectful, we're humans over here.

Just closing this immediately because 'this is by design' without any explanation was not really respectful either. Multiple ppl made issues about this and asked related questions about this on stackoverflow. Iam sorry if you found my surprised comment disrespectful.

Showing files from imports is very much by design, it's fundamental to SDK-based projects. Without it, you would have zero files listed in a project by default as the default set of globs come from imports.

But just putting them in the root of a project is very confusing. Its not clear why and where these files come from for the user and trying to delete them results in a error. It should be made more clear that a package and what package is adding these files (in addition to properly making them readonly but thats a different issue).

Package authors should be using false on these content files if they are not intended to be shown in the project, I'll continue to let NUGet track adding a feature to control this via NuGet/Home#4856.

I added <Visible>false</Visible> but all it does is make the item invisible in the current project. It doesn't change anything about the nuget package so this doesn't seem to be anything of use for package authors.

As for the folders still being visible, this is owned by an external team to this respository and was being tracked by https://developercommunity.visualstudio.com/content/problem/495189/parent-folder-of-items-marked-as-visiblefalse-stil.html. It was closed as lower priority but I've converted it to a product Suggestion, and reopened it so you can vote it on. It might take a while to reflect on the Developer Community side.

👍

[ilexp]

I'll continue to let NUGet track adding a feature to control this via NuGet/Home#4856.

As for the folders still being visible, this is owned by an external team to this respository and was being tracked by https://developercommunity.visualstudio.com/content/problem/495189/parent-folder-of-items-marked-as-visiblefalse-stil.html. It was closed as lower priority but I've converted it to a product Suggestion, and reopened it so you can vote it on. It might take a while to reflect on the Developer Community side.

Thanks! 👍

Package authors should be using <Visible>false</Visible> on these content files if they are not intended to be shown in the project

Sorry if I'm asking dumb questions 😄 But can you clarify where we'd add a Visible tag on the package author side, and whether (or how) that would behave differently from overriding it in the consuming .csproj? (We're using .nuspec content files, if that's relevant)

If there is an intended way how to handle scenarios like this, that would be a good start for us.

[davkean]

xUnit does this, here's an example: xunit/visualstudio.xunit@d54a5e4

I can't find the original source of above, but you can explicitly include the items via a targets file and specify visibility. There's no built-in way to do this via the contentFiles feature.

[Kryptos-FR]

@davkean This doesn't solve anything for people using such package if the author did not put it as not visible, especially for old nuget packages.

And it shouldn't even be a responsibility of the package/library maker. Some users of those packages might decide they want to display, some might not. So there should be an option to show/hide this on a per-project basis.

Look at #3302 for an idea of the mess it can be. I have to scroll down more than 60 items before seeing the first class of my project.

So here is a proposal:

<PackageReference Include="ThirdParty" Version="1.0">
    <ContentFilter Include="*.config" Visible="False" />
    <ContentFilter Include="*.dll" Visible="False" />
</PackageReference>

[davkean]

This issue has been closed in lieu of NuGet/Home#4856. Use it for any proposal you have.

[kirsan31]

@davkean What about:

As for the folders still being visible, this is owned by an external team to this respository and was being tracked by https://developercommunity.visualstudio.com/content/problem/495189/parent-folder-of-items-marked-as-visiblefalse-stil.html. It was closed as lower priority but I've converted it to a product Suggestion, and reopened it so you can vote it on. It might take a while to reflect on the Developer Community side.

?

Let's go:

1. https://developercommunity.visualstudio.com/content/problem/215427/unmanaged-dlls-of-a-nuget-package-show-u-in-the-ro.html Mar 14, 2018, closed - 3 votes.
2. https://developercommunity.visualstudio.com/idea/1079955/parent-folder-of-items-marked-as-visiblefalse-stil.html Mar 15, 2019, open - 6 votes.
3. https://developercommunity.visualstudio.com/content/problem/653392/cannot-hide-folder-containing-linked-items-in-the.html Jul 19, 2019, open - 13 votes. In my experience 13 votes is not a little for a bug in developercommunity...

And many topics here: this one, #4602, #5859 ...

You can somehow influence to this external team?

[davkean]

To follow up, the issue where linked folders continue to show after their items have been marked Visible=false, has been fixed in the latest 16.8 Preview.

[davkean]

Correction; the fix will be in 16.9 Preview 2 when it releases.

[kirsan31]

Yea thank you, I just wanted to write that at 16.8. p6 still doesn't work...

[xoofx]

Correction; the fix will be in 16.9 Preview 2 when it releases.

I tried it on 16.9 Preview 2 and it's working, fantastic, looking forward to it!