Slnf files #21745

Pilchie · 2020-05-12T17:40:47Z

No description provided.

pranavkm · 2020-05-12T18:13:31Z

src/Mvc/Mvc.slnf

@@ -0,0 +1,132 @@
+{
+  "solution": {


We've been using slnf files in Blazor and MVC for a while now and personally I have been fairly happy with it.

In Mvc, we've had a smaller projection of project files that specifically include projects in the Mvc folder: https://github.com/dotnet/aspnetcore/blob/master/src/Mvc/MvcNoDeps.slnf. The big issue with a smaller projection is that VS expects referenced projects to have already been built. You'll get weird errors from MSBuild if referenced projects weren't already built. Usually I run a build[cmd|sh] on the cli before I launch a slnf and all's well with the world. On the upside, smaller projections have a much faster dev inner-loop. On projects like MVC or Blazor which reference nearly everything in the repo, this makes a big difference.

Going back to slnf files, there are a couple of annoying usage issues with it.

Adding additional projects to an slnf file isn't as simple as using the Add Existing Project dialog. I've typically ended up hand-editing it (not difficult since it's just JSON).

CLI commands such as dotnet build \ dotnet restore etc do not work on slnf files, unlike sln files

VS sometimes does not add slnf files to it's recently used project history. This one was aggravating enough that I filed a feedback issue - https://developercommunity.visualstudio.com/content/problem/660100/slnf-do-not-get-added-to-the-recent-projects-and-s.html.

As an aside, were you able to open the AspNetCore.sln file on a laptop? This was a while back, but I remember trying to build a large sln and it would take VS minutes before the UI became usable. It's rare you would want to open the root-level sln file, but it would be good to ensure it's not entirely unusable if you needed to open it.

I was able to open it on my home desktop (which is an 16-proc Xeon with 32GB of RAM). It wasn't pleasant until all the design time builds had run and been cached in the .vs folder, but after that it wasn't bad at all.

I haven't tried on my SurfaceBook 2 yet.

Adding additional projects to an slnf file isn't as simple as using the Add Existing Project dialog.

Does this apply to creating new projects as well. For example, will devs need to add a project to AspNetCore.sln then hand edit the relevant *.slnf files?

Adding a project to a slnf file adds it to the backing sln. But I couldn't figure out what the gesture was to update the slnf file too while it was doing so.

Pilchie · 2020-05-12T18:29:18Z

Note: This is just a proposal to discuss at @dotnet/aspdoi. If people don't want this experience, we don't have to use it.

dougbu

This looks awesome to me but I'd like to hear from a couple of people who check out this branch and use it for their normal work (before cherry-picking changes into a branch targeting 'master').

dougbu · 2020-05-12T19:16:49Z

Oops, if we do move forward with this (please 😃), WebHostFunctionalTests needs a touchup to look for src/DefaultBuilder/DefaultBuilder.slnf instead of DefaultBuilder.sln. Either that or change the tests to work without src/ at all i.e. make these tests runnable on Helix.

I didn't look through the failures enough to see if we have other tests that depend on where a *.sln file is located.

JvanderStad · 2020-05-13T01:26:38Z

For those who stumbled into this PR (like me): https://docs.microsoft.com/en-us/visualstudio/ide/filtered-solutions?view=vs-2019

Looks very useful. SLNF all the things! 🏆

javiercn · 2020-06-09T15:54:29Z

These are my findings based on looking playing with it:
PROS:

Single solution file for loading the entirety of ASP.NET Core (not sure if you can actually build)
Projects added to the slnf file get automatically added to the global solution
Can quickly access and load dependent projects, modify them and build them in place.
- This allows you to load the entire dependency graph for a project, which is cool as prevents having to open another VS instance.

CONS:

Can't remap the folder structure inside the solution files (at least that I know)
- You can right click "scope to this" in the folder you care about within VS to avoid having a deep nesting structure.
No access to Solution Items (belong to the global solution)

OBSERVATIONS:

VS performance doesn't seem to be affected (loading the slnf takes a similar amount of time on my box, navigation and other code activities doesn't seem to be affected)

Pilchie · 2020-06-29T23:39:49Z

Wish I had merged this before @pranavkm re-added the blazor wasm stuff :(

Pilchie · 2020-07-01T00:08:08Z

Okay, I basically redid the work here against a current version of the master branch. I think this is ready for review now. A couple of things I've learned:

The folder structure comes from the backing sln file. Since I generated a brand new sln file, it got the default folder structure that dotnet sln add gave it. We can tweak that over time.
There are 150-ish *.*proj files in our source tree (excluding the "ref" projects @dougbu will be deleting soon) that aren't in AspNetCore.sln because they weren't in any of the sln files before. I'll post that list somewhere for people to look at and add the ones they want to.

SteveSandersonMS · 2020-07-01T11:15:51Z

I wonder if we'll end up seeing a lot of merge conflicts on the global .sln file if there will be a lot more centralised churn on it now.

Was the AspNetCore.sln file in this PR built in a one-time way, or is there some shared script to regenerate it? Being able to regenerate it would give people an objectively correct way of resolving merge conflicts.

javiercn · 2020-07-01T12:24:34Z

I wonder if we'll end up seeing a lot of merge conflicts on the global .sln file if there will be a lot more centralised churn on it now.

Was the AspNetCore.sln file in this PR built in a one-time way, or is there some shared script to regenerate it? Being able to regenerate it would give people an objectively correct way of resolving merge conflicts.

Yes, it might be nice to have the script in the repo so that we can discard changes and re-run when dealing with merge conflicts.

Pilchie · 2020-07-01T18:48:21Z

Happy to share, but the way it's written right now, it will break once this is merged - it goes looking for all existing *.sln files, generates an slnf for it, storing each *.*proj*, and then running dotnet sln add for each project.

Once the existing sln files go away, it won't know what to add.

dougbu · 2020-07-01T19:09:40Z

Once the existing sln files go away, it won't know what to add.

Then again, it should reasonable to write a script that traverses the repo and adds everything it finds to the solution using dotnet sln add. One difficulty might be handling the exceptions e.g. some testassets/ folders. And, another might be recreating whatever folder structure we want (long term) in the solution file.

We already traverse the project files (to confirm their names are unique) in eng/scripts/CodeGen.ps1. That script also uses dotnet sln today to ensure listed projects actually exist.

Pilchie · 2020-07-01T19:12:14Z

The exceptions are the problem there - currently there are about 150 *proj files that aren't in the sln (though I'm not sure if some/all/most/ should be).

dougbu

This looks good so far but doesn't change the startvs.cmd files yet. In addition, should probably change the dotnet sln example in docs\BuildFromSource.md to mention AspNetCore.sln and the various *.slnf files.

Pilchie · 2020-07-01T19:17:30Z

Hmm. I did change the startvs.cmd files locally, must need to push again. Need to fix some tests, and will update BuildFromSource.md as well.

dougbu · 2020-07-01T19:19:21Z

Agreed @Pilchie. In addition, the Code Check job is failing because a few of the Blazor projects no longer exist.

Pilchie · 2020-07-01T19:23:02Z

Closing in favor of #23581 :( Not sure why pushing here isn't working.

pranavkm reviewed May 12, 2020

View reviewed changes

dougbu mentioned this pull request May 12, 2020

Replace .sln files with .slnf and add one repo-wide .sln file #10464

Closed

dougbu approved these changes May 12, 2020

View reviewed changes

Pilchie added the area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework label May 13, 2020

Pilchie added 2 commits June 29, 2020 16:30

Add AspNetCore.sln and slnf files

9781ba2

Remove existing sln files replaced by slnfs

735c550

Pilchie force-pushed the slnf-files branch from 786ea1d to 735c550 Compare June 30, 2020 23:45

Pilchie marked this pull request as ready for review July 1, 2020 00:10

Pilchie requested review from BrennanConroy, halter73, jkotalik, SteveSandersonMS and Tratcher as code owners July 1, 2020 00:10

dougbu reviewed Jul 1, 2020

View reviewed changes

Pilchie closed this Jul 1, 2020

Pilchie deleted the slnf-files branch July 1, 2020 19:23

Slnf files #21745

Slnf files #21745

Uh oh!

Conversation

Pilchie commented May 12, 2020

Uh oh!

pranavkm May 12, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Pilchie May 12, 2020

Choose a reason for hiding this comment

Uh oh!

dougbu May 12, 2020

Choose a reason for hiding this comment

Uh oh!

pranavkm May 12, 2020

Choose a reason for hiding this comment

Uh oh!

Pilchie commented May 12, 2020

Uh oh!

dougbu left a comment

Choose a reason for hiding this comment

Uh oh!

dougbu commented May 12, 2020

Uh oh!

JvanderStad commented May 13, 2020

Uh oh!

javiercn commented Jun 9, 2020

Uh oh!

Pilchie commented Jun 29, 2020

Uh oh!

Pilchie commented Jul 1, 2020

Uh oh!

SteveSandersonMS commented Jul 1, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

javiercn commented Jul 1, 2020

Uh oh!

Pilchie commented Jul 1, 2020

Uh oh!

dougbu commented Jul 1, 2020

Uh oh!

Pilchie commented Jul 1, 2020

Uh oh!

dougbu left a comment

Choose a reason for hiding this comment

Uh oh!

Pilchie commented Jul 1, 2020

Uh oh!

dougbu commented Jul 1, 2020

Uh oh!

Pilchie commented Jul 1, 2020

Uh oh!

Uh oh!

pranavkm May 12, 2020 •

edited

Loading

SteveSandersonMS commented Jul 1, 2020 •

edited

Loading