Support file nesting implemented in for dotnet core web projects

[abpiskunov]

See this request here: https://github.com/aspnet/websdk/issues/248

Nesting went live in 15.6 Preview 3 and there were requests for other dotnet core projects to support that.

To support nesting, project needs to have following capabilities:

To add default nesting behavior for your project type, a provider needs to be implemented.

Contact me for details when ready.

[SharpNoiZy]

Since nearly one year open...to enable something that another Team of your Company has already developed perfectly...can you please copy&paste the Code over and support also library Projects...

[drewnoakes]

@SharpNoiZy we recently added support for automatic dynamic nesting of files in .NET Core projects (via #4378) which will hopefully improve the situation for your library projects in VS2019.

This issue is tracking porting the configurable nesting capability of web projects to non-web projects.

The default nesting rules we've added should cover the majority of library project use cases, without the need for configuration. What kinds of files would you expect to be nested in your library projects?

[SharpNoiZy]

We use in our hole Company (100 Devs, 5 Teams) CQRS with this Config.

{
  "help": "https://go.microsoft.com/fwlink/?linkid=866610",

  "dependentFileProviders": {
    "add": {
      "fileSuffixToExtension": {
        "add": {
          "Request.cs": [ "Command.cs", "Query.cs" ],
          "Response.cs": [ "Command.cs", "Query.cs" ]
        }
      }
    }
  }
}

So, you have: Command, CommandHandler and Response under one element.
I dont't understand why you don't use an working solution from your ASP.net colleagues and have to develop your own. Will your solution now also work with ASP.NET Projects or just for non ASP.NET Projects?

[drewnoakes]

Thank you for the example.

It won't be possible to do that automatically for libraries until we add support for custom nesting rules in this project-system. We're aware of the WebToolsExtensions implementation and have looked at porting it, but the amount of work involved is non-trivial and must be considered along with our other priorities.

[fschmied]

I'm probably misunderstanding the issue, but doesn't the configurable file nesting already work with SDK-style class library projects?

[fschmied]

See https://github.com/aspnet/websdk/issues/248#issuecomment-364520896 - just need VS 15.6 or higher, add the capabilities to the csproj file and configure the nesting. We're using this successfully with SDK-style library csprojs (also in a CQRS context, funnily).

[drewnoakes]

@fschmied thanks for pointing out a workaround.

@SharpNoiZy can you try adding the following to your library's project file?

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

You'll need to reload the project, but should then see nesting support.

[SharpNoiZy]

@drewnoakes We have this WORKAROUND in place, but it's exactly that.
It feels hacky and the fear that this Workaround functionality will be removed with some VS Update is Always there.

There should be one official solution for all Project types.

[drewnoakes]

That's what this issue is tracking.

[pawchen]

How to specify the custom nesting profile file in the project file? Want to include the json file along with the project instead of somewhere in user appdata.

[NickCraver]

@DiryBoy You can create as the magical name .filenesting. Ours is solution level but it may search for it up the root and work per-project and such like most things...I just haven't tried multiple or anything there.

I love this feature and it cleans up our .csproj files tremendously. We have a pattern of Class.cs and Class.Area1.cs/Class.Area2.cs (partials so functionality or relationships are grouped). In the old world, it's a 1 line <Compile> for Class.cs and 3 lines (because of <DependsUpon>) for each of the others, so 7 lines total. With this nesting defined once we go from 7 to 0 in the .csproj.

We're currently using the workaround of defining the <ProjectCapability>, but I'd love to see this just work for people and have it move to where that's possible.

[drewnoakes]

Saint, you're looking at this so I've assigned it to you. Feel free to update/dupe this issue as necessary.

[jjmew]

We will be tracking this as part of #5722

[odalet]

@DiryBoy You can create as the magical name .filenesting. Ours is solution level but it may search for it up the root and work per-project and such like most things...I just haven't tried multiple or anything there.

I love this feature and it cleans up our .csproj files tremendously. We have a pattern of Class.cs and Class.Area1.cs/Class.Area2.cs (partials so functionality or relationships are grouped). In the old world, it's a 1 line <Compile> for Class.cs and 3 lines (because of <DependsUpon>) for each of the others, so 7 lines total. With this nesting defined once we go from 7 to 0 in the .csproj.

We're currently using the workaround of defining the <ProjectCapability>, but I'd love to see this just work for people and have it move to where that's possible.

@anyone interested in using @NickCraver trick, note that the file at your solution level must be called .filenesting.json, not .filenesting, at least the former worked for me, and not the latter.

It also seems that, for non-Web projects, DynamicDependentFile capability is not necessary. I only have this in my csproj:

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

[nathan-alden-sr]

@odalet I'm trying this same workaround in VS Community 2022 RC3 and it's not working.

[PuzhengCao]

Not working with the latest right now - VS Professional 2022 V17.0.4

[NickCraver]

I don't have any new information since joining (will ask!), but for those it's not working for: do you have the web payload for VS installed? That's where the actual functionality resides and why it only worked on web projects by default (1:1 with needing the workload anyway), at least previously - I'm not sure if anything changed in VS 2022.

[gfraiteur]

Same problem here. I got it nicely working for VS 2019 but it broke in VS 2022.

[fschmied]

New issue for VS 2022: #7939
@gfraiteur @PuzhengCao @NickCraver @nathan-alden-sr

[drewnoakes]

This is being actively worked on. There are performance implications for us to turn it on by default for all projects.

The manual approach in VS2022 changed. I'm sorry there was no update posted here until now.

Manually enabling file nesting for non-web projects in VS 2022

<ItemGroup>
  <ProjectCapability Include="ConfigurableFileNesting" />
  <ProjectCapability Include="ConfigurableFileNestingFeatureEnabled" />
</ItemGroup>

[gfraiteur]

Thank you. I can confirm it works for us.

Is there a way for a nuget package to suggest/install nesting rules?

We need these:

{
  "help": "https://go.microsoft.com/fwlink/?linkid=866610",
  "dependentFileProviders": {
    "add": {
      "extensionToExtension": {
        "add": {
          ".t.cs": [
            ".cs"
          ],
          ".t.txt": [
            ".cs"
          ],
          ".Aspect.cs": [
            ".cs"
          ],
          ".Helper.cs": [
            ".cs"
          ],
          ".cs.html": [
            ".cs"
          ]
        }
      }
    }
  }
}

Our use case is a custom test framework.

[drewnoakes]

Is there a way for a nuget package to suggest/install nesting rules?

Not that I know of, though I am not an expert. Could you open a new issue for this please?