Provide an option to hide content files from project tree in new-style csproj

[davidmatson]

I'm currently using VS 2015 with project.json with a number of sources-style NuGet packages (packages that only have contentFiles with c# code as *.cs files).

There are quite a few files that come in this way, so having them not show up in the project root is key. When I try migrating to the new-style csproj, that's what happens, so I'm currently blocked (stuck back in project.json-style NuGet).

Two possible solutions here (I'm sure there are others as well):

1. Change back the default for contentFiles to be hidden from the csproj like they were with project.json.
2. Provide a per-csproj setting to turn off showing referenced packages' contentFiles in the project tree.

If there's a workaround I could use at the moment (perhaps getting the files to appear somewhere nested under a project folder rather than showing up directly in the project root), that would be great to know as well. (Hopefully long-term there is a way to control where these files appear, unless the default changes back. Project root-only doesn't seem sufficient for a large number of content files.)

[davidmatson]

See also #4166 which may be related.

[davidmatson]

I think there's a slightly broader question here to consider as well - if contentFiles do appear, how should they show up in the project tree? One possible option (my preference) would be to have them appear underneath the Dependencies -> NuGet node in the project (show the .cs files directly underneath the name of the package that includes them).

There may be other/better options as well. Having the ability to show these files is nice for setting breakpoints, but IMO we should have something better than just dumping everything in the project root.

[davidmatson]

I'm currently using the following workaround (thanks to @emgarten for the idea):

  <ItemGroup>
    <Compile Update="@(Compile)">
      <Visible Condition="'%(NuGetItemType)' == 'Compile'">false</Visible>
    </Compile>
  </ItemGroup>

[davidmatson]

Here's a fairly simple option that might improve things:
The props file currently does something like this:

    <Compile Include="$(NuGetPackageRoot){package ID}\{package version}\contentFiles\cs\net45\{relative path}" Condition="Exists('$(NuGetPackageRoot){package ID}\{package version}\contentFiles\cs\net45\{relative path}')">
      <NuGetPackageId>{package ID}</NuGetPackageId>
      <NuGetPackageVersion>{package version}</NuGetPackageVersion>
      <NuGetItemType>Compile</NuGetItemType>
      <Private>False</Private>
      <Link>{relative path}</Link>
    </Compile>

Note that the link item just has the relative path of the cs file. Add some prefix to the link item, such as "NuGetContent{package Id}":

      <Link>NuGetContent\{package Id}\{relative path}</Link>

Unfortunately, I think this approach would only work item types like Compile that aren't binplaced; items that are copied to the output directory would get messed up if they have some kind of prefix added to them, because it would affect the output path.

[davidmatson]

The idea of the prefix was inspired by this technique from the pre-NuGet 3 days:
https://nikcodes.com/2013/10/23/packaging-source-code-with-nuget/

Though I'd suggest omitting the version from the path as only one version of a package can be installed anyway (and making the path longer might contribute to MAX_PATH issues; not sure if that matters in a Link though).

[davidmatson]

Actually it looks like there's a more fundamental problem here and something like the NuGetContent approach mentioned above is essential to correct behavior, due to collisions with multiple packages using the same file name. See #5048 for details.

[tmat]

I'm using the above workaround like so:

<Compile Update="@(Compile)">
  <Link Condition="'%(NuGetPackageId)' != ''">%(NuGetPackageId)\%(Link)</Link>
</Compile> 

This serves two purposes:

1. It's nicer to not have a bunch of links from referenced packages pollute the project root.
2. Correctness in case there are two files of the same name in the referenced packages.

This should imo be the default.

[leak]

What is the state of this issue?
MySql.Data is shipping tons of content files that are polluting my solution explorer in VS 2017. I cannot remove or edit those file and folder links in any way without getting tons of errors.

[emgarten]

@leak use @tmat's example to remove the links.

[leak]

I did and changed it to "Content", but it does not get rid of folders for me.