Show content files from nuget packages as a distinct group in solution explorer

[srivatsn]

Content files from packages are either source files passed to the compiler or other files treated as content.

In either case it would be good to show them in the solution explorer. One way to represent them might be similar to a readonly linked file (maybe a different icon to distinguish) along with the rest of the files.

It may also be nice to show them under the package node itself but maybe unnecessary and maynot even be obvious.

[davkean]

Before showing them in Solution Explorer, other than under packages, I already discussed with NuGet that we should move the adding of these files so that we can pick them up during evaluation time and not requiring design-time builds. One way we could do this is by generating static <Content/> at the same time that we generate the props/target imports instead of dynamically creating them.

[davkean]

Everything shown in the source tree today other than dependencies are evaluation time.

[srivatsn]

Synced with @yishaigalatzer - NuGet will work on doing static generation of the content includes so that we can pick them up during evaluation time. (Otherwise the UX would be bad since the tree will jump around based on design time builds for different projects completing at different times).

We'll need to mark these files as readonly for now and real editing and overriding will be enabled with #604. One approach to that could be that while generating the items for the files, NuGet can add some metadata to them that tells us that we need to make them readonly.

[srivatsn]

Currently because NuGet includes the content files statically in the generated props file, they show up in the tree as being included from the NuGet folder and this is confusing.. See #1506. We should give a different visual treatment for these or group them differently under a virtual node.

[tannergooding]

I was going to look at taking this on since it seems fairly straightforward.

Today, you will get something like the following:

However, it sounds like we want to modify this so we have an explicit 'Content Files' node:

• ClassLibrary3
  • Dependencies
    • NuGet
      • Microsoft.VisualStudio.Setup.Configuration.Native.AnyCPU (1.3.269-rc)
    • SDK
  • Content Files
    • x64
      • Microsoft.VisualStudio.Setup.Configuration.Native.dll
    • x86
      • Microsoft.VisualStudio.Setup.Configuration.Native.dll
  • Class1.cs

or possibly:

• ClassLibrary3
  • Dependencies
    • NuGet
      • Microsoft.VisualStudio.Setup.Configuration.Native.AnyCPU (1.3.269-rc)
        • Content Files
          • x64
            • Microsoft.VisualStudio.Setup.Configuration.Native.dll
          • x86
            • Microsoft.VisualStudio.Setup.Configuration.Native.dll
    • SDK
  • Class1.cs

Is that correct?

[abpiskunov]

1. Hold on , i am working on a change that would redesign Dependencies tree and you work will be lost. 2. in your sample you are showing "dlls" which we already show under package anyway - would it be duplicated ?

Also it is not straight forward anyway - all packages with their dependencies are received form a designtime build events (not evaluation which gets only top level packages), you would have to change designtime targets and tasks that generate nuget package hierarchy and follow rules that we have for packing data there.

Also - is it really ok to show content files under Dependencies node ? We show there "dependencies" binary of client "packages" , not a content files ...

[tannergooding]

in your sample you are showing "dlls" which we already show under package anyway - would it be duplicated ?

In this case, these DLLs are native (not managed) and must be included as 'ContentFiles' to get the build to copy them to the output directory.

Also - is it really ok to show content files under Dependencies node ? We show there "dependencies" binary of client "packages" , not a content files ...

As @srivatsn indicated: "We should give a different visual treatment for these or group them differently under a virtual node."

This is why I gave two examples and attempted to confirm the intended design here.

[abpiskunov]

Sounds good. I personally like the second sample since it shows what is brought by each package, which could be a pattern for the future and other dependency providers could follow it. However let's wait for @srivatsn and @davkean votes. (if we chose second option later we could add a Filter View that would show all content files brought by dependencies which would do same thing as sample 1 essentially) Implementation wise those sample would be pretty different though.

[bording]

What about source files that are brought in via ContentFiles? It would be weird to find those inside the Dependencies tree, since they are actually compiled as part of the project.

[adamralph]

Content files are currently shown in the solution explorer. Does this issue need re-titling?

[srivatsn]

Changed the title to track showing them in some distinct groups

[nkolev92]

@davkean
Can this considered to be the tracking item for display contentFiles in legacy csproj?
Or is there a better one for that?
I was unable to find one.

[davkean]

Nope please file a new bug for that.

[drewnoakes]

This has been fixed in the dependencies-tree-performance branch which will merge for 16.7.

[bording]

@drewnoakes Looking at the images in #6066, it's not yet clear to me what this experience looks like fully.

For example, do those content files still show up in the project as the currently do in addition to the new location in the package's node?

EDIT: Ok, I see that the data.txt is still displaying. I overlooked that originally. Glad to see that is unchanged.

In that case, any chance of #2141 being prioritized?