Project-system: File Nesting Not Working for all Class or Shared Library Projects

[vsfeedback]

_This issue has a corresponding ticket on Developer Community. Please vote and comment there to make sure your voice is heard._

_Copied to AB#986508_

---

File Nesting is just not working for all Class or Shared Library Projects

---

Original Comments

Visual Studio Feedback System on 11/03/2019, 05:51 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Drew Noakes [MSFT] on 13/03/2019, 00:19 AM:

Thanks for your feedback. Could you please provide some more details to help us investigate this issue? A screenshot would be great, along with what files you expect to appear nested. Also please confirm whether you're seeing the nesting you expect in certain project types, and if so, which ones.

Kearin on 08/05/2019, 00:12 AM:

This might be when you create a class A.cs and then auto generate code into a file A.B.cs. It used to be that A.B.cs would nest under A.cs in the solution explorer. This behavior was similar to specifying A.cs in the project file.

Alex Engblom on 25/06/2019, 05:37 PM:

At least the basic 'extensionToExtension' rule of nesting .cs.d.ts -> .cs does not seem to work in class libraries. This would be great to trim out the common entities project etc... Doesn't work with changing Standard Settings to 'Web' nor by creating custom solution level .filenesting.json file with appropriate settings. Tested with VS2017 and VS2019.

David Adams on 04/07/2019, 10:21 AM:

This is so frustrating because file nesting is essential to any large project. It was so simple with non .NET core projects with Mads K. extension because this was completely hands-off and worked automatically. It does not appear, nor is it made clear, that the filenesting.json works with class libraries. The workaround seems to be to edit each and every csproj file for class libraries and individually hard-code each nested file such as:

 <Compile Update="$(ProjectDir)\Org.*.cs">
      <DependentUpon>$(ProjectDir)\Org.cs</DependentUpon>
    </Compile>

However, file nesting is lost when the project is unloaded for nested files which are in subfolders. So the following:

 <Compile Update="$(ProjectDir)\Model\Org.*.cs">
      <DependentUpon>$(ProjectDir)\Model\Org.cs</DependentUpon>
    </Compile>

will work temporarily but when you exit VS and reload the file nesting will be lost for nested files in subfolders. The only way to get it back is to re-edit the csproj file and modify each dependency again to trigger the file nesting. It would really be nice if the same filenesting settings for a VS .NET core solution would apply to all projects and not just the web project. I am using VS 2019 16.1.4.

Alex Engblom on 04/07/2019, 07:38 PM:

Just found out this issue in github https://github.com/dotnet/project-system/issues/3242 . Workaround suggested by @Drew Noakes [MSFT] - adding following elements in .csproj did the trick for me. For now. For .NET Standard 2.0, didn't work with Framework 4.7.1.

<ItemGroup>
<ProjectCapability Include="DynamicDependentFile" />
<ProjectCapability Include="DynamicFileNesting" />
</ItemGroup>

David Adams on 05/07/2019, 09:24 AM:

Nice find Alex E - I will follow that github thread. Unfortunately the addition of the ProjectCapability elements to the .csproj file this does not seem to help with .NET core class libraries which have file nesting in project subfolders. Just as before, once the project is reloaded the file nesting is lost in any subfolders, and the only workaround is to re-edit the .csproj file and save while the project is open.

Visual Studio Feedback System on 25/07/2019, 08:51 AM:

This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.

---

Original Solutions

(no solutions)

[NickCraver]

FWIW, we are doing the Directory.Build.props approach as well:

<ItemGroup>
  <ProjectCapability Include="DynamicDependentFile" />
  <ProjectCapability Include="DynamicFileNesting" />
</ItemGroup>

It it helps, the reason I was given last time on this being restricted to ASP.NET Web projects by default is it's supported by _that workload in Visual Studio_. So the assumption is: dealing with ASP.NET? You're on that workload...or things are funky anyway. So that's where it's lit up.

To light it up for all projects, it'd have to move to another workload in Visual Studio, which means a team ownership change...and I'm not sure how that part works :)

[drewnoakes]

@NickCraver we are investigating the cross-team move, to make the configurable nesting implementation that's currently available in web projects available for all SDK-style projects. This wouldn't require any special workloads beyond those you need to open SDK-style projects anyway.

[swesonga]

A fix for this issue is in Visual Studio 16.7 Preview 1 and will need to be enabled by checking the Tools > Options > Environment > Preview Features > Enable Configurable File Nesting option then restarting Visual Studio.

[BrunoBlanes]

Lovely fix.

[anrichter]

Hi,

I miss this feature in the final version from Visual Studio 16.7. (16.7.1)
The Visual Studio 16.8 Preview contains the file nesting feature.

[swesonga]

Hi,

I miss this feature in the final version from Visual Studio 16.7. (16.7.1)
The Visual Studio 16.8 Preview contains the file nesting feature.

Sorry there was no additional follow-up here. This feature is still only usable in the Preview builds because #1176 needs to be fixed before enabling it in the RTM channel.

[anrichter]

Thanks for the explanation.

[julealgon]

@swesonga could you please elaborate why exactly fixing #1176 is required to promote this to RTM?

Would it be possible to untie these issues from one another? #1176 has been open for 3+ years now with no fix in sight. It was recently removed from 16.8 timeline as well, which means we'll probably end up another entire major VS release at least without proper file nesting support.

[swesonga]

@julealgon The reason this depends on #1176 is that the bug there can potentially start happening in more scenarios with file nesting enabled. @lifengl has a fix for that issue is in the works for 16.9.

[julealgon]

I assume it happens on more specialized scenarios right @swesonga ? Can't this be shipped as a preview feature in VS 16.8 RTM and be promoted to non-preview later in 16.9?

I guess the benefit of doing that depends on how long it will take for 16.9 to be available and the fix to be in place. Do you have any ETA?

[swesonga]

@julealgon The nesting feature allows for custom nesting rules, which can possibly introduce cycles in the dependencies. It may make sense to view that as a more specialized scenario, but the possibility of VS crashing in that scenario means the feature is not allowed to be promoted to RTM. As far as ETA, we're most likely looking at 16.10 for turning on this feature by default since 16.9 is for the loop dependencies fix.