File nesting in Solution Explorer is inconsistent and incorrect

[thomas-darling]

The Solution Explorer for ASP.NET 5 MVC projects has several major problems - one of them is file nesting. The below issues affect Visual Studio 2015 Update 1 with ASP.NET 5 Release Candidate 1.

tl;dr

• Please fix nesting rules for .less, .scss and .sass, so those files are nested under .html.
• Please fix incorrect nesting that sometimes appear after renaming/moving/copying files and folders.
• Please provide an option to disable all file nesting, and eventually, options to configure nesting rules.
• Please fix other critical Solution Explorer issues - this is just one of them, and there are many more.

File nesting is inconsistent when nesting files under .html.

The .less and .scss files should be nested under .html. Those files compile to .css just like .ts compile to .js and they are just as much part of the view component.


In fact, if we only have a .css file in there, then it is nested as expected, so clearly .less and .scss should also be nested:

While the above is clearly a bug, and a very annoying one at that, the rules for other file types are less obvious, but should maybe also be considered... maybe .json should also be nested under .html?
It probably contains either settings, string resources, or data for that view component, so it seems resonable to me, although I consider this far less important than getting the style sheet nesting fixed.

Those nesting rules have been inconsistent ever since they were introduced in ASP.NET 5, and it really needs to be fixed. Sure, everything compiles just fine, but I'm getting really pissed off looking at this mess in my Solution Explorer every day. Inconsistencies like this makes the whole concept of nesting seem like an annoyance more than a help, as it raises the obvious question "if only some files are nested, then why nest anything at all - that's just an extra click to get to the .ts file". Which brings me to...

File nesting can be annoying

While the fundamental idea of file nesting is not nessesarily bad, it can be very annoying at times, which is why, as a minimum, I want an option to disable all file nesting - and ideally, options to configure the nesting rules.

Consider this folder structure, where the folder already represents a container for the component:

Here the file nesting provides no benefit at all, and actually just introduces a really annoying extra click to get to the .ts file. A possible fix for this might be to only nest files if the folder name is different from the name of the .html file, but this might also be wrong - for example, a folder named tabs representing some fancy tabs component might actually contain multiple elements that work together, e.g. tabs.html/js, tab-pane.html/js and tab-button.html/js, and in this case we do want nesting for all three of those. Therefore, I strongly believe an option to simply disable all nesting is the best option here - and it is very much needed, because despite this example, we do have projects in which the nesting provides absolutely no value and represents a major annoyance.

One could also argue that the .html file should actually be nested under the .js file.
Consider an Angular 2 application, where the .ts file represents the actual Component, annotated with metadata specifying either the path to the .html file representing its view, or if the view is small, a string representing the markup of the view. Same for styles, where the metadata in the .ts file specifies either the path to the .css file, or a string representing the style rules. Here, both the view and the style sheet is clearly dependencies of the .ts file, so it would make sense to nest them below that...

An alternative idea

Alternatively, you could consider a completely different approach to nesting, where the part of the file name the files have in common, is used to show a "virtual folder" containing all the files - then file nesting could be used only for things like transpiler generated files. The image below is a concept I mocked up to illustrate this idea:

Here, all the files have the "foo" part of their name in common, and is therefore nested under a "foo" node in Solution Explorer. However, in the file system, the actual files are all located in the components folder, so in the code the path would be app/components/foo.js - nice an clean, works for any file type, and makes no assumptions about whether .html or .js is more important.

Going further with this idea, the IDE could also be smart, so when selecting this "virtual folder", it could maybe somehow open all the foo.* files in a split view (ignoring transpilation output of course), thus providing a quick way to see all the component code at once. Just a thought...

File nesting is broken

Not only is file nesting inconsistent, and sometimes annoying, but it is also broken.
Here are two cases of incorrect behavior I managed to reproduce - unfortunately, this does not seem to fail consistently, so it can be hard to reproduce - but it does happen often enough to be annoying.

Please take those Solution Explorer issues seriously - I've provided feedback about multiple critical issues several several months ago, and thus far nothing has improved. Solution Explorer still hangs or crashes the whole IDE when a large number of files is modified/moved/copied/renamed, it still has annoying, inconsistent and buggy file nesting, and it still constantly gets out of sync with the file system, crashing first the project system and eventually the whole IDE. I'm more that a little concerned about seeing a release candidate label on something this buggy and unpolished - if this is indeed what you intend to release, then we intend to find another IDE for our frontend development.

[thomas-darling]

@abpiskunov Just want to draw your attention to this issue - I see you have been commenting on the other issues related to file nesting, so thought you might be interrested in this one too :-)

[abpiskunov]

Thanks for detailed post. First of all I would like to split it into separate topics:

1. Functionality:
   a. Inconsistent behavior that you reported was just taken from existing WebEssentials extension, which exist for some time already. You had a valid point for me, however we need to consider other users also - if they consider it "inconsistent". In any case we will discuss that.
   b. Extra clicks when folder has same name as foo file in your example. It does not seem wrong to me, since usually you would have several files and in most cases they would be different from folder name. Change in behavior might seem inconsistent to others... Your suggestion with virtual folder , actually does same extra click but for all scenarios.
   c. All above could be fixed if we had options to disable nesting and configure rules. Nesting settings should/could be stored on VS and on solution/project level.
2. Bugs
   a. I could repro bugs you reported for dragging and renaming folder. I will check if they are in our code or in underlying common project system (CPS) and they should be fixed in U2 (also we do have tests for nesting scenarios , I will check why it was not caught)
3. Overall Solution explorer performance (it is not really related to nesting itself, so let's keep it in separate issue where it is reported)
   This is a known issue and is being investigated by CPS team , not web tools. All changes are scheduled for U2 at the moment

[abpiskunov]

Bugs
TFS 175047,
TFS 175046

Disabling and settings:
TFS 175048

[thomas-darling]

@abpiskunov Thanks for the response!

I absolutely agree that making this configurable on a project/solution level is by far the best solution, as the definition of what is inconsistent is clearly not the same for everyone. Very much looking foreward to seeing those options :-)

However, knowing that it might take some time to get that kind of configurability done though, I would very much prefer to also see an adjustment to the current nesting rules as a temporary solution, as the current ones really make no sense to me at all. In my opinion, the only valid options would be to either also nest .less and .scss under .html, or to nest nothing at all under .html. I really hope this is a change you can get into U2.

Regarding my alternative "virtual folder" suggestion, you are right - it does introduce the same extra click. However, the point is that it does so consistently for all file types. No need to worry about new nesting rules when someone comes up with a new .fancy style format - it would just nest all foo.* files under the virtual foo folder. Anyways, it is just an half-baked idea :-)

And good to hear the performance issues are being looked into - it's a really big problem for us. The other, and equally critical, issues I mention also include very frequent crashes (as in, multiple times per day) when mainipulating files and folders in Solution Explorer. I just posted a separate issue (#350) detailing those - not sure how those things might be related.

[abpiskunov]

Issue 350 is CPS issue and I am opening an additional bug to track that . Thanks for posting stack traces. If you could also catch dumps when VS crashes it would be perfect. I will comment there.

[abpiskunov]

Updates:
bugs 175046 and 175047 fixed (nesting while dragging and wrong nesting after renaming parent folder)

[mcquiggd]

On the subject of file nesting; when T4 templates are used to generate a file (a single file), the file that is output (irrespective of its extension), is correctly nested underneath the T4 template that generated it.

However, when the Solution is closed and reopened, the T4 template and output files are displayed as siblings, without any nesting.

Reproducible with RC1 Update 1 and latest Visual Studio tooling.

[abpiskunov]

What is the sample T4 template you used?

[mcquiggd]

@abpiskunov

Actually I was just about to update my answer with more information:

I have an example on Github, that includes both an MVC5 and an MVC6 project.

The MVC6 project exhibits the behaviour I describe above, but the same templates output is correctly nested in the MVC5 project, when reopening the solution.

https://github.com/Pro-Coded/MVCMagic

[abpiskunov]

@mcquiggd Could you please list step by step instructions to repro your problem to save time?

[mcquiggd]

@abpiskunov

It is pretty simple actually:

1. Download and open the solution.
2. Open the solution folder 'Samples'.
3. Open the project 'MVCMagicSampleMVC6BP', and navigate to the folder '/Constants/MVCMagic/'
4. Notice that the .generated.cs files are not nested underneath the .tt file.
5. Right click on any .tt file, and select 'Run custom tool'.
6. The output file is regenerated, and is now correctly nested.
7. Close and reopen the solution.
8. Notice that the .generated.cs files are not nested underneath the .tt file.

To compare that with the behaviour of an MVC5 project:

1. Open the project 'MVCMagicSampleMVC5BP', and navigate to the folder '/Constants/MVCMagic/'
2. Notice that the .generated.cs files are nested underneath the .tt file.
3. Right click on any .tt file, and select 'Run custom tool'.
4. The output file is regenerated, and is still correctly nested.
5. Close and reopen the solution.
6. Notice that the .generated.cs files are nested underneath the .tt file.

David

P.S The .tt templates are identical in both the MVC5 and MVC6 projects.

The MVC6 project lacks the ability to right click, and select Properties of a .tt file and set the normal settings we see in other project types; it does not appear to be fully recognised within an ASP.Net 5 project type.

[abpiskunov]

Yes, I see what is going on. Since our projects are dynamic and folder based, nesting is also calculated dynamically, xproj doe snot store any metadata comparing to csproj.

I opened a TFS 194772 to track that.

[sayedihashimi]

Thanks for the feedback everyone. We have a backlog item to enable customize the nesting behavior. We won't be able to get to that in RC2 but hopefully the release after that we can get it in, but I'm not sure at this point yet.

[binoypatel]

Same issue with VS2015 Update 3, asp.net rtm, check the screenshot
1). notice use.js which has user.service.js which is incorrect
2). notice user-list.component.html which has user-list.component.ts which is incorrect

[abpiskunov]

this is one of our nesting rules. For some people it does not work - like in this case, some prefer to have it. Unfortunately we can not configure nesting rules at this point and it should be added in next releases.

[nvivo]

Just adding to the discussion, I'm waiting for some configuration on this as well.

An issue I'm facing is that typescript files are nested inside HTML files, and I'd like to see the opposite. When working with angular components for example, script files are the "main" files, and the html templates are optional dependencies.

[atrauzzi]

Why not just allow us to configure our own nesting conventions? I have a number of places in my projects where that would be useful.

[abpiskunov]

Configuration of nesting rules is on our list and we are thinking how/where settings would live. No final ETA yet, see updates in coming releases.

[icegnome]

+1

Not sure if this is a direct result, or something else. But I loose syntax highlighting//auto complete in the TS file when it is nested under the html file.

[mtosic]

We have feature-per-folder structure, and keeping max 7-8 files per folder. File nesting is annoying in this case, because Angular controller (feature.js), route definition (feature.route.js), service (feature.service.js) and feature module (feature.module.js), are all nested under feature.js.

I know that there we cannot configure nesting rules. But can we disable file nesting on project/solution level?

[abpiskunov]

Unfortunately there no way to turn them off at the moment ..

[kingmotley]

@mtosic I would expect the default to be exactly what it is currently doing, and thinking that feature.route.js is a subcomponent of feature.js. May I suggest trying the File Nesting extension from Mads which allows you to nest files however you want, including being able to disable file nesting at the solution level?

[TDK1964]

This nesting issues is a right problem for those of using "feature folders". Please fix it soon.

[yaronmil]

having the same problam

[Liteolika]

This is really annoying. At the moment i need to break the naming rules to get rid of the nesting.

[tmc101]

This is awful.

Here's my typescript-heavy Angular application - following the Angular style guide for file naming conventions:

I cannot see a single one of my TypeScript component files!

They are all nested inside their html templates - which is the exact opposite of what is needed.

I completely fail to see how you can introduce an arbitrary file nesting scheme and then provide no way to switch it off.

Bring back .csproj !

[webtools-bot]

The GitHub Issue Tracker for the aspnet/Tooling repo is being deprecated in favor of Visual Studio's Report a Problem tool.

If this issue is still a problem with the RTW release of Visual Studio 2017, please report a new issue using the Report a Problem tool. While you can still use .NET Core and ASP.NET Preview tools with Visual Studio 2015, Visual Studio 2017 is now the officially supported tool for developing .NET Core and ASP.NET Core projects.

By using the Report a Problem tool (available in both VS 2017 and VS 2015), you can collect detailed information about the problem, and send it to Microsoft with just a few button clicks. See Visual Studio's Talk to Us page for more details.

Please use the discussion topic here for feedback and questions on the deprecation of this issue tracker. Thanks!

[wanton7]

@grokky1 this horrible behavior is already reported to https://developercommunity.visualstudio.com/content/problem/22011/do-not-nest-typescript-files-under-html-file-with.html and it's marked as "Closed Won't fix"

Based on comments in that link new system for reporting visual studio problems seems to be based on vote count so chances are this broken nesting system is never getting fixed.

Probably time to report a new problem in that new horrible system.

Added new report here (feel free to vote) https://developercommunity.visualstudio.com/content/problem/95247/file-nesting-in-solution-explorer-is-inconsistent.html

[abpiskunov]

Nesting feature was postponed to next releases because of higher priority issues. However since Dev15 RTM there is a workaround which allows you change any nesting rules that you would like on your machine see discussion here : #889 (comment) , current location of the settings file is under your VS install path: Common7\IDE\Extensions\Microsoft\Web Tools\ProjectSystem\toolSettings.json. This is undocumented since design for nesting feature is not complete yet, and this settings file is just a workaround for corner cases.

In the future please use Report a problem tool as it was suggested above.

[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/

[NickCraver]

@AngelosP I'm psyched that this has become a thing, and looks like it'd be very useful, but the ASP.NET Core-only part right now really kills it. I have so many use cases that are library, is there any hope of seeing more general support happen?

[abpiskunov]

It is tracked in the core project system repo: dotnet/project-system#3242 . In meanwhile you enable this feature manually for your core class libraries or console apps by adding:

[AngelosP]

@NickCraver I'm really sorry it took me a while to respond, I had the wrong rule in Outlook ... silly me. Yes, we want to make this available for more project types. Your feedback will help us get this done quicker, so thank you for asking for it!