VS2017 - Please bring back file nesting in .NET Core projects

[ciel]

In Visual Studio 2015, we had file nesting via this amazing extension

However, in Visual Studio 2017 RC, that functionality no longer works outside of the built in file nesting for things like JavaScript/TypeScript.

This was a really valuable tool, and the author (@madskristensen) says that it can't be made to work in ASP.NET Core unless the tooling team makes changes. This was a very important part of my workflow for C# files, and I hope this is the right place to bring it up. I couldn't find another suggestion venue.

[scottaddie]

The nesting of the .bowerrc file under bower.json in an ASP.NET Core project is gone in VS 2017 RC as well. This nesting feature was particularly useful in reducing noise within Solution Explorer.

[mlorbetske]

Thanks for the suggestion! We're actively working on this at the moment

[ciel]

I'm really glad to hear it. I know this seems like a silly feature to some, but it's actually pretty major to me.

[mlorbetske]

TFS Bug#264170

[ciel]

Hey... I notice this is still broken in RC3. Is there any hope of this in RTM?

[stefan505]

Same with RC4. Any news?

[abpiskunov]

Due to outstanding amount of work in new csproj based project system we did not have time to do full support for custom nesting rules. It is scheduled for next update. However we did add a way for users to manipulate existing nesting rules via json file located here: C:\Users(youruser)\AppData\Local\Microsoft\VisualStudio\15.0_(yourinstanceid)\toolSettings.json (now this file lives under your VS install path: Common7\IDE\Extensions\Microsoft\Web Tools\ProjectSystem\toolSettings.json). You can deactivate some of the rules there or add some other file extensions, or change some rules order.

Please treat that json file as temporary workaround, don't build extensions around that until more permanent changes will be shipped in coming updates.

[ciel]

This is a good answer. Thank you. Not having the feature is frustrating, but just upfront being told why it isn't in there is very helpful.

[seangwright]

I would actually like to disable nesting of .ts files under .html files in the same directory.

I'm used to working in VS Code on browser based client applications and the rules for nesting (hiding) in that IDE are pretty customizable.

Is there a way to turn off nesting in ASP.NET Core projects in Visual Studio 2017?

I see that if I change the solution to a "Folder View" then the files are no longer nested. Is this my only option?

[abpiskunov]

Yes, you could remove all nesting rules form your C:\Users(youruser)\AppData\Local\Microsoft\VisualStudio\15.0_(yourinstanceid)\toolSettings.json file and restart VS.

[Beej126]

@abpiskunov - can you give a little example of toolSettings.json structure... i tried this for nesting xaml.cs under .xaml for XamForms .Net Standard library project and restarted VS2017 (26628.10) but didn't seem to change anything:

   "fileToFile": {
      ".xaml": [
        ".xaml.cs"
      ]

[lenniebriscoe]

Does this apply to aspt.net core projects only? i.e. If I open up a folder (i.e. not a solution or project) of web files and in the Team Explorer select "Show Folder View", the nesting rules don't seem to apply. Would be great if it could be extended to there as I use the VS IDE to work on projects which are primarily worked on by non-VS IDE developers.

[abpiskunov]

It is only for dotnet core projects for now.

[abpiskunov]

@Beej126 fileToFile rule need full file names , not just extensions. You need to use extensionToExtension rule.

[ciel]

I appreciate that support was added for netcoreapp, but I feel that the actual request was taken a bit too literally. This needs to work in netstandard as well to be of much use. I'm pretty sure most large applications have one or more netstandard libraries.

Good design even encourages dividing up a project into smaller pieces that are isolated from each​ other, and for netcoreapp, that's usually going to be netstandard.

Please look into this. It's just such a necessary feature for organizing. I find myself longing to go back to Visual Studio 2015 because of the lack of this.

[abpiskunov]

@ciel I am a little confused with what you referring as netcoreapp and neststandard... Dotnet Core projects can have both of them as targets. Did you actually mean two different project system types: DotNet Core (new project system) vs full .Net framework (classic project system)?

[blovell33]

Seems like file nesting is working in .NET Core web projects, for example:
HomeController.Foo.cs is automatically being nested under HomeController.cs

Doesn't seem to be working in non-web projects however, which was previously working in 2015.
For example, ModelExtensions.Foo.cs is not being nested under ModelExtensions.cs.

This was working in 2015, is this functionality going to be added back into 2017?

[ristogod]

We are using EF Core and running "dotnet ef migrations". The migration classes created have a *.Designer.cs file also, and none of them are nesting. How soon can we expect a fix? It's very jarring to open that folder now that it expands double the size and we lose all that screen real estate.

[abpiskunov]

cc @srivatsn

[robertmclaws]

FYI, nesting seems to be totally broken with .NET Standard Class Library in VS2017.3 Preview 2. Just used dotnet new classlib --force to upgrade a library that uses a .TT file to generate a bunch of classes, and not only are the classes not nested, but a) the toolSettings.json file is not on my machine, b) the File Nesting addin won't work, and c) there appears to be no documentation for how to specify nesting in the new .csproj file format, so I can't do it myself.

Would love to help get this fixed before 2017.3's RTM, as this is causing problems for us.

Thanks!

[robertmclaws]

I spoke too soon. According to this link, the new .csproj way to do it is as follows:

  <ItemGroup>
    <Compile Update="*.Generated.cs">
      <DependentUpon>Entities.tt</DependentUpon>
    </Compile>
  </ItemGroup>

The key is that, because all files are included by default, you're updating an existing compilation reference, not creating a new one. You can use wildcards to do whatever you want... in this case I append .Generated.cs to all of my files generated by T4 templates, so the fix was pretty easy.

Hopefully the tooling can get updated so that Mads' nesting tool can work properly.

Thanks!

[CodingSamurai]

I'm seeing nesting not working in VS2017 for .NET Core console applications. So if I add support for appsetttings to my app and then add appsettings.development.json it doesn't properly nest.

This seems like a MAJOR step back. Really disappointed in the VS team for removing functionality which worked in VS2015.

[camp-007]

The 'toolSettings.json' work around would be nice, however, my findings show that this only applies to projects using the web SDK:

<Project Sdk="Microsoft.NET.Sdk.Web">

But this does not work for class library or console projects using 'Microsoft.NET.Sdk':

<Project Sdk="Microsoft.NET.Sdk">

There are many cases outside of web projects where the ability to nest files without explicitly declaring each one is very beneficial. Is there a way to get the 'toolSettings.json' file to work for both project types?

[abpiskunov]

Yes, we are working to extend nesting support at the moment, it should be available in coming updates whenever is ready.

[abpiskunov]

based on your VS version nesting should be working, what exactly you mean by "nesting still not working"? Can you please provide more details?. Currently we are planning to update nesting in the bigger update that might happen in the end of the fall.

[abpiskunov]

@grokky1 to disable nesting you can remove everything from: VS install path: Common7\IDE\Extensions\Microsoft\Web Tools\ProjectSystem\toolSettings.json, and restart VS

[abpiskunov]

to disable nesting you can remove everything from: VS install path: Common7\IDE\Extensions\Microsoft\Web Tools\ProjectSystem\toolSettings.json, and restart VS

[HarelM]

This is the full path to the file:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Microsoft\Web Tools\ProjectSystem\toolSettings.json

Here's the content of my toolSetting.json file, I updated it a bit to nest typescript and css under html files:
The below is a bit counter intuitive, at least for me, since the property of the array is which file to nest and the array are values in which to nest under, but once you understand it, it makes sense.

{
  "dependentFileProviders": {
    "addedExtension": {},
    "pathSegment": {
      "*": [
        ".js",
        ".css",
        ".html",
        ".htm",
        ".less",
        ".scss",
        ".coffee",
        ".iced",
        ".config",
        ".cs",
        ".vb",
        ".json"
      ]
    },
    "extensionToExtension": {
      ".js": [
        ".coffee",
        ".iced",
        ".ts",
        ".tsx",
        ".jsx"
      ],
	  ".ts": [
		".html"
	  ],
      ".css": [
        ".less",
        ".scss",
        ".sass",
        ".styl",
		".html"
      ],
      ".html": [
        ".md",
        ".mdown",
        ".markdown",
        ".mdwn",
      ],
      ".map": [
        ".js",
        ".css"
      ],
      ".svgz": [
        ".svg"
      ],
      ".designer.cs": [
        ".resx"
      ],
      ".cs.d.ts": [
        ".cs"
      ]
    },
    "fileToFile": {
      ".bowerrc": [
        "bower.json"
      ],
      ".npmrc": [
        "package.json"
      ],
      "npm-shrinkwrap.json": [
        "package.json"
      ],
      "yarn.lock": [
        "package.json"
      ],
      ".yarnclean": [
        "package.json"
      ],
      ".yarnignore": [
        "package.json"
      ],
      ".yarn-integrity": [
        "package.json"
      ],
      ".yarnrc": [
        "package.json"
      ]
    },
    "filePartToExtension": {
      "-vsdoc.js": [
        ".js"
      ]
    },
    "allExtensions": {
      "*": [
        ".tt"
      ]
    }
  }
}

[ctopher31]

Please make nesting an opt-in. I prefer a flat structure without hidden files.

[veton]

Tried adding SpecFlow feature mapping to toolSettings.json:

...
"extensionToExtension": {
  ".cs": [
    ".feature"
  ],
  ".js": [
...

Restarted VS, nesting still not working:

VS Version: 15.4.0
Project type: netcoreapp2.0

[abpiskunov]

extensionToExtension means that file names should be identical but only extensions are different. In your case if you remove extensions you specified you would have different file names: UsersApi (.feature) and UsersApi.feature (.cs), that's why it does not work.

In order to make it work do:
".feature.cs": [ ".feature" ]

[AngelosP]

I just wanted to let everyone know that since Visual Studio 2017 15.6 Preview 4 (which was made available a few days ago) users have the ability to control how file nesting works in Solution Explorer.

Check out this blog posts for more details:
https://blogs.msdn.microsoft.com/webdev/2018/02/07/file-nesting-in-solution-explorer/

[camp-007]

@AngelosP That looks great! I would LOVE to see this happen for class library projects in addition to just asp.net core projects.

[evil-shrike]

I have difficulties with nesting in netcore projects as well.
I have a VSIX extension with my DSL (Modeling SDK, former DslTools). When installed this extension allows users to create models with diagrams. So usually there are two files: a model and a corresponding diagram. In .NET Framework projects diagram is nested into model (via DependentUpon in csproj). In .net core project there's no any nesting. But in ASP.NET Core projects there's nesting! I can't understand how VS decides to nest diagram files but it does (obviously my files aren't mentione in Web Tools\ProjectSystem\toolSettings.json).

The biggest problem is that it makes the extension crashes with NullReferenceException which happens somewhere inside VS internals. Here's the bug I created https://developercommunity.visualstudio.com/content/problem/207301/nullreferenceexception-while-saving-a-dsl-model.html for this issue.
In short NullReferenceException happens on a call to SubordinateFileHelper.GetChildProjectItemFileNames method. It happens only in ASP.NET Core projects and due to the nesting. In .net core without nesting no exception happens.

So my question - why do I have nesting for custom files in asp.net core projects? and how to disable it?

[abpiskunov]

Null exception you reported is not related to nesting and will be handled by corresponding team owning the stack.

About the nesting question you have: please upgrade to VS 2017 15.6 Preview 4, we added support for manipulating nesting rules and creating your own. See this blog post: https://blogs.msdn.microsoft.com/webdev/2018/02/07/file-nesting-in-solution-explorer/ .

[evil-shrike]

Null exception you reported is not related to nesting and will be handled by corresponding team owning the stack.

why are you so sure? it happens only if diagram exists and nested (ie. it doesn't happen in other .net core projects where there's no nesting and it doesn't happen in aspnet core project if I delete .diagram file)

as for file-nesting-in-solution-explorer, thanks it's interesting, but it's a feature for users as I understand. is it possible for an extension to control its files nesting?

also I'd like to understand why is it happening for my custom extensions in asp.net core (.xdm and .xdm.diagram files)

[abpiskunov]

I am sure because nesting feature does not do anything with physical files, it just applies some settings in memory. In your scenario you are trying to save the file and it fails while trying to get files properties, which are beyond of control of nesting code path. It is underlying layer issue - CPS (Common Project System). It should not throw in general and even if it goes to that code path because of some nesting logic it is also not right, it should not. Anyway, as i said, owners would follow up with the issue on developer community.

About nesting, yes, if you are creating an extension you can control what would be Default nesting settings for projects working with your extension. Look at Microsoft.VisualStudio.ProjectSystem.Components.dll. You would need to implement a MEF export for IDefaultNestingProfileProvider with Order that is higher than default providers in VS. Apply your extension's capability string to the provider for it to be applied only to projects working with your extension.

[abpiskunov]

If you need more details for implementation we could take it offline and continue via email. This issue will be closed soon.

[evil-shrike]

@abpiskunov thanks for explanation, I'll try to implement the mentioned interface, in case of difficulties I know who contact to ), thanks again.

[DerekZiemba]

@abpiskunov It's too early to close. File nesting is still unavailable in v15.6 under the following conditions.

• When .csproj uses: <Project Sdk="Microsoft.NET.Sdk">
• With a Library output type: <OutputType>Library</OutputType>
• TargetFrameworks contains netstandard: <TargetFrameworks>netstandard2.0</TargetFrameworks> . I believe netcore is also affected in non-web projects.

FileNesting does actually work if those conditions aren't met.

I've even tried adding the following in the csproj to force it, but had no luck:

<ItemGroup>
	<Compile Update="RuntimeCompiler.*.cs">
		<DependentUpon>RuntimeCompiler.cs</DependentUpon>
	</Compile>
	<Compile Include="RuntimeCompiler.*.cs">
		<DependentUpon>RuntimeCompiler.cs</DependentUpon>
	</Compile>
</ItemGroup> 

[abpiskunov]

I would need to look at your sample app. The only thing for nesting to work is capabilities added to your project. By default Microsoft.NET.Sdk does not carry them, only web sdk have them. Thats said nesting enabled by default only for Asp.Net Core projects. If capabilities are added to Microsoft.NET.Sdk project then nesting will also be enabled, the only difference is you would need to select Web settings in the Solution Explorer toolbar explicitly, since there no Default nesting settings for Microsoft.NET.Sdk projects.

OutputType and TargetFrameworks are irrelevant for nesting since this feature is working in a different way comparing to what DependentUpon does. Or more precisely it uses differnt types of settings which are independent on msbuild items. If DependentUpon is specified it wins, otherwise new nesting logic kicks in.

Sample with DependentUpon that you posted did work for me. It probably means that something is wrong in the "old" DependentUpon based nesting, however, as i said, new nesting logic is different and still should work.

[Chavoshi]

Please add the file nesting support for Microsoft.NET.Sdk same as the Microsoft.NET.Sdk.Web.

[abpiskunov]

@Chavoshi This repo is for web issues onl and web projects already have nesting. You need to open issue at https://github.com/dotnet/project-system .

Also to unblock yourself you could add these capabilities to your projects:

and select Web settings in the Nesting toolbar selector.

[Chavoshi]

Thanks @abpiskunov for the explanation.

[ranouf]

@HarelM , I followed your instructions, but my angular files are still no grouped:

Is there a specific thing I missed to make it work?

[HarelM]

Latest version of vs 2017 has this built in, no need to hack config files any more...

[SWarnberg]

Any updates on this lately? Is this tracked somewhere else? (Referring to Microsoft.NET.Sdk targeted projects).

[HarelM]

@SWarnberg See my last comment...

[SWarnberg]

Hmm, I have 15.7.5 and it doesn't work there for ,net standard projects. Are you referring to something else?

[HarelM]

The following tutorial worked for me as far as I remember:
https://blogs.msdn.microsoft.com/webdev/2018/02/07/file-nesting-in-solution-explorer/

[SWarnberg]

Yeah, I consider that as a "hack" since it doesn't work well in a distributed team. Yes, you can check it in to source control, but most of us expect common files like appsettings.json to be nested "out of the box" in other project types than just ASP.NET Core.

[abpiskunov]

@SWarnberg this issue is opened in aspnet repo and nesting is working in ASP.NET Core project, isn't it? If you want this feature to work in other project types then please add feedback for those project types (in their repos or through developer community web site) to increase count and visibility. This issue in aspnet repo is closed now.