Aspnetcore: Replace .sln files with .slnf and add one repo-wide .sln file

[natemcmaster]

Managing individual .sln files has been error prone and problematic (see #7740 ).

VS2019 has a new feature, filtered solutions, which are meant to address some of the reasons why we created many smaller .sln files in the first place. Let's investigate adding one .sln to the repo root which points to everything, and then use .slnf to create "scopes".

https://docs.microsoft.com/en-us/visualstudio/ide/filtered-solutions?view=vs-2019

[natemcmaster]

cref https://github.com/Microsoft/msbuild/issues/4097 - these files can't be used for build.cmd yet :-/

[natemcmaster]

Was talking to @Tratcher about this. He had some feedback about the quirks of .slnf which might make us want to hold off on making this the default.

[Tratcher]

I set one up for StaticFiles and it did address the perf issues I had with solution load and build. https://github.com/aspnet/AspNetCore/blob/master/src/Middleware/StaticFiles/StaticFiles.slnf
Using 16.1.0 I saw the following oddities:

• Load Project Dependencies is not recursive.
• Any changes to the solution filter must be manually saved via SaveAs.
• Solution:Path is absolute by default. You have to hand edit it to make it relative.
• Every time you do SaveAs it overwrites Solution:Path with an absolute path.

[SelmaI]

@Tratcher, thank you for your feedback. These're great insights. I will open internal bugs, can you also file one suggestion to improve solution filters with these features?

[SelmaI]

@natemcmaster , i would like to under your need for build.cmd? What is preventing you to use the repo solution (the one solution filter is based on) ?
Thanks!

[natemcmaster]

@Selmal: ... your need for build.cmd...

Oh, so many many reasons. Other languages have Maven, Gradle, Make, setuptools, npm, etc. for running a sort of standard set of commands (restore, compile, package, test, sign, etc.). In .NET, there is no such thing (at least not that Microsoft is willing to officially support...see CakeBuild.net), so most .NET repos use a shell script instead.

Solution files files do not satisfy this need. The only thing they are good for is opening Visual Studio. They are pretty much useless for CI and command line builds. 

If you want more context on this repo's specific build.cmd script, I suggest reaching out to the .NET engineering team (dnceng@) that I used to work with (I'm at Amazon now, but still love .NET :) )

[davidfowl]

@SelmaI if solution files were truly msbuild files then we could use them. The problem is that we need someplace to put logic that runs per solution, not just per project.

[dougbu]

Reassigning to @Pilchie because he kindly did #21745. Much appreciated❕

[davidfowl]

How does this work with startvs?

[dougbu]

@davidfowl @Pilchie didn't update the individual startvs.cmd files in #21745 but e.g. .\startvs.cmd src\Mvc\Mvc.slnf in the repo root Just Works:tm: 😺

[javiercn]

Closing this since the work here is done. Thanks @Pilchie

[Mohit-Chakraborty]

Using 16.1.0 I saw the following oddities:

• Load Project Dependencies is not recursive.
• Any changes to the solution filter must be manually saved via SaveAs.
• Solution:Path is absolute by default. You have to hand edit it to make it relative.
• Every time you do SaveAs it overwrites Solution:Path with an absolute path.

I wanted to give an update on some enhancements we have made to the solution filters feature -

1. Project nodes have 2 separate commands related to loading referenced projects - one to load direct dependencies and one to load the transitive closure of all dependencies.
2. A prompt appears on the top of the Solution Explorer if the set of loaded project changes. The prompt has a link which can be used to update the filter.
3. Solution paths used to be absolute if the filter was not saved in the same folder. Now, we write the relative path in all cases.
4. VS title bar and task bar show the name of the filter and not just the underlying solution. This should make it easy to identify when multiple filters are opened for the same solution.