You Need to Update Your .NET Solution Files!

[@ronsijm]

Finally. The original format looked like the Visual Basic team made it

[@ZintomV1]

They probably did

[@josephmoreno9733]

Jajaja

[@rodrigodearcayne]

I was thinking the same 😆

[@aborum75]

Yeah, just before the first developer left and the rest of the team took over .. and kept it.

[@keithfranklin214]

Just in time for me as I am about to retire

[@antonmartyniuk]

Old sln files are a nightmare when resolving GIT conflicts

[@jeffbarnard348]

Indeed. But understanding them has made me look good over the years lol

[@erikgrundy]

hallelujah. getting merge conflicts in sln files was such a pain

[@Fred-yq3fs]

Merge conflicts nightmare? A dream now. Love it.

[@no-bias-]

@@IIARROWS have you ever managed thousand lines of XML files?

[@ericvruder]

Merging the current solution format is a nightmare, this looks pretty good. I loved how the SDK style projects made files auto-discoverable, making merge issues with those project files disappear completely. I hope they have something similar here as well.

[@CheetahNr1]

TIP: Enter '*' for the filename in the project/solution file picker dialog and you can choose the slnx-file too. :-)

[@maksymkyian4920]

I hope they will also add the possibility to make a solution file without paths to .csproj files (so it would automatically find it, similar to how .csproj files work now). Or at least a setting that will force devs to keep the "logical" solution file structure the same as the physical one. Really annoying when somebody accidentally creates projects out of "src" folder and stuff like that.

[@Phumy]

"LINQ in the description"

[@mciejgda88]

Doug is last person I expected to pop out in THIS video

[@dcuccia]

Nick shows us AHLLLL the QUIRKS and FEATURES of .Net.

[@SergeyPogreban]

How about build configurations? Where will the configurations be stored with new solution format?

[@krccmsitp2884]

As sub-elements, not shown in this video.

[@VladyslavHorbachov]

That's a great update, looking forward to use in the stable release. Also, I'd like to have some kind of way to set the startup project from this solution file.

[@chris-pee]

I suspect the startup project is an IDE-specific config, which they're trying to avoid in the new format.

[@VladyslavHorbachov]

@@chris-pee Good point

[@chris-pee]

@@dalemac89 yeah that sounds like a proper solution (pun not intended)

[@davidhunter3605]

One thing the video didn't cover was the nodes in the XML. These are great and will definitely allow better tooling around dependency management, graphs etc...

[@precmv]

This is great! At my place of work, we have 350+ projects in our mono repo. I've written tooling to generate solution files in various combinations. It was a pain to figure out how the solution files are supposed to look, so this is very welcome! I don't quite understand the reasoning behind the "name" of folders being a path, but other than that it looks great. I also need to see how they allow for projects in a solution to be "not built" which is currently achieved by leaving out the project from the build configuration part of the solution.

[@daasdingo]

They are probably a path because that is what folders are. They are a virtual filesystem on top of the real filesystem. I never got why anyone needs this, but maybe its because of the horrible tooling not letting you move projects easily?

I guess they want a way to avoid extra indentation. E.g. if you have a folder that only contains folders, and you don't allow paths, you would need two levels. By allowing paths you can have just one level like ....... I do prefer XML structure to mimic the folder structure, though.

[@jeroen7362]

Much better! Now what i need is a disable attribute on the project so OR be able to comment things out, but so that it does not disapear when visualstudio or riders updates the project file now i can copy the very big mother solution with 100 projects in it, disable/comment out bunch of projects that i do not need currently to work on and have a nice couple of subsolutions to work with for better focus and speed when i rebuild all etc.

[@vyrp]

You can look at solution filters.

[@davepusey]

It's just standard XML, so the usual comments should work.

[@firestrm7]

So how it looks when build config is changed? (e.g. exclude project build from release config) Old format contained this, too.

[@W1ese1]

Would love to get to know this too

[@mikolash8246]

I think it won't be a problem to configure it with XML, it will be even more intuitive

[@carlinhos10002]

Probably with XML conditionals

[@sadiablo]

Looks like which isn't much clearer in my opinion but oh well, at least you can have NoBuild for multiple configurations in one line

[@t3mp0_732]

That's a really good question

[@eye776]

There's a class for parsing solution files: Microsoft.Build.Construction.SolutionFile

[@safalin1]

This is a million times better. Glad it's finally getting updated - no more hassle with merges!

[@p.j.wilkins1321]

Definitely an interesting look at Quirks and Features.

[@Draenal]

this is incredible! I've tried to build some custom build tooling in the past and these files were just difficult enough to parse that it was easier to do it at a project level.

[@denys-p]

I remember times (still doing some migrations for other teams/projects) when Framework project files were common thing. And almost no one had any wish to edit them manually and actually look into them at all. People (including myself) just used IDE and really hoped that there will be no conflicts. Nowadays I can easily go to project file, remove few things, add few options I never thought existed before, reorganize it and it still works and looks nice and readable. Same with configuration files - Web.config was really bad and config transformations were even worse. Json files and layered configuration structure is so much better. I really hope that with solution files we will have similar transformations and we finally won’t dread them anymore.

[@aldelaro]

One thing I wonder is where are the build configs? The second part of the original had bingdings for build configs which I had to interact with once and it was painful, but I understood what they were doing...where do they end up now?

[@gileee]

Aren't configurations loaded from each .csproj file now anyway. Like, Debug;Release And then you do DEBUG;TRACE ...

[@aldelaro]

@@gileee Nah, so what the sln had were bindings to csproj configs. It meant that if you changed the build config, it could be bound to different configs of different csproj. This is useful because I had to deal with a case where the csproj configs were different than other csproj, but I could still say that this build config meant these csproj configs. So no it's a different thing.

[@gileee]

@@aldelaro Honestly sounds like an awful hack, but I get you. I just put my configs in the Directory.Build.props so they're global and never worry about it.

[@AJax2012]

uuugh, finnally. I can't believe it took this long to fix the solution files to be more readable. Looks amazing.

[@TuxCommander]

Nice, finally setting up a my planned Builder project becomes more handy with this.

[@yoanashih761]

I'm curious why Microsoft hasn't opted for JSON or YAML as the format for their project/solution configuration files.

[@EricSellers-m3k]

Don't have the preview loaded yet, but Nick, can you order your solution folders by just changing the order of the elements in the file? Or do you still have to play the "00 First Folder", "01 Second Folder" game?

[@cdoubleplusgood]

Would like to see how explicitly entered build dependencies and build configurations show up in the new format. Is there a specification available already?

[@casperhansen826]

I worked with it a couple of times, we had a solution with a couple of applications and then more than 2500 code libraries, one of the applications would generate a code library so it generated a C# code file, a project file and then added it to the solution, those libraries were some code that opened a web site or api and extracted some data from it. These libraries should also be uploaded to the servers so they could go directly to production, for this purpose it would run through the solution file to extract the libraries and read all the project files to extract their references to build a new package for the servers

[@scdecade]

They need to make is easy to view the .slnx (and .sln) files from within Visual Studio

[@KotyBashford]

I agree, You shouldn't have to switch to folder view to open them within VS.

[@dalemac89]

​@@KotyBashfordyeah, and solution level directory.packages.props files for centralised package management.

[@Nekroido]

I usually unload my solution by popping into the folder view and then highlight the .sln file. I'm toying with Avalonia and MAUI which bundle mobile and macOS projects that break for me and I have to remove them manually

[@PatricSjoeoe]

Finally! :) If you have 30+ projects, this file is crazy 😂

[@tempusmagia486]

Hey Nick, two things, is there a way to bring the progress from the old dometrain to the new? I forgot where I left in many courses. Also I think it would be nice to make a video about Rider or comparison with Visual Studio because for example there are things that rider decides to implement by itself which is good because for example the coding conventions are way too easy in Rider but visual studio it is so good to manage .NET projects. For me I use Rider when coding but Visual Studio for managing, specially because Rider sometimes includes unnecessary libraries that Visual Studio doesn't. I wish you could give us some knowledge on that topic

[@JohannesHansen1980]

Would be nice if they added a way to include projects with a glob pattern or something similar. So all projects in the "./tests/.../*.csproj" folder is automatically added to the "Tests" solution folder. For large solutions that would be awesome. Also the same thing for external files added to the solution please. For files it would also be nice to be able to "mount" a folder on disk as a solution folder. Such as project documentation stored as markdown files in a folder hierarchy somewhere.

[@delpher1983]

There are things like this, with which MS gets late not by years, by decades! But finally it is here. We can celebrate 🎉

[@SG_01]

Solution files are downright ancient, it's good to see them getting a makeover.

[@jfftck]

I’m not a fan of XML, YAML or TOML is easy to read and doesn’t require closing tags that only take up lines without adding any more information. But I would agree that this is at least much more readable and doesn’t require searching for depend configurations throughout the file.

[@Daniel15au]

The YAML spec is very complex with lots of room for ambiguity, and Microsoft already have a good XML parser for project files. It makes more sense to have consistency between project files and solution files instead of using totally different formats.

[@jfftck]

@@Daniel15au I understand the complexity, but they are also using JSON for Azure configuration, so I don’t think that complexity in parsing is a key factor for dismissing another format. I have horrible experience with Java and it had the configuration in XML files that would get so complicated that it was not as human readable. Don’t forget the whole point of this change, it is to make the file more human readable and that does mean using more complex parsing.

[@Stimpy77]

When you right-click on a solution and choose "Configure Startup Projects" and have multiple projects running, each with a different runtime configuration (Release vs Debug vs something custom), extra stuff gets stored in there. Don't get me wrong, the new format, while I haven't looked into this, will probably handle that stuff just fine and those configs will just be nice, clean attributes in the project nodes in the XML, I'm sure.

[@mirrorless_mirror]

I like this new XML solution format. Great improvement.

[@SoWhat07]

This is the most important fix from year when implemented garbage collector in c# ;) Can not image how many bugs are made due to current solution formating.

[@nove1398]

This looks much better, I accidentally wrecked my project by messing with the .sln file before. Had no idea what i was doing

[@rezameshksar503]

When you said "This", I thought it was KZbin bug as recently I am watching car reviews a lot and thought KZbin just uses my history :) It was very interesting feature though.

[@KeesAlderliesten]

The preview features are directly in the Tools menu.. 'Manage Preview Features', 2nd from the top..

[@rGunti]

Hell yeah! Finally. Can't wait for this to go into GA. The amount of times I had to fix my SLN manually because of that stupid format… man!

[@mikewagner2299]

But how are configurations handled?

[@meirkr]

Very good improvement. I propose naming the extension .slnx

[@Macronaso]

Man I wish they kept the json format they started to use wayyy back when core started. But this is much better than the current format.

[@T___Brown]

agreed. That was really nice. Even for csproj with the version inline editing/autocompletion was amazing.

[@Ba-gb4br]

Solution files are MsBuild files and MsBuild always used xml

[@CodingHaribo]

It sure is about time they sorted out the SLN file. What would really put a cherry on top, is if I could add package-references that all projects (of a type) in the solution would inherit.

[@egorshiyanov1206]

Will this feature come to dotnet CLI? Great to see that sln files are starting to look similar to csproj files 🎉

[@ABC_Guest]

Was there any functionality lost with this new format? At the very least it seems like there's less information in the new slnx files. I'm not the best developer & I've never really figured out what to do with the "Any CPU" / "x86" / "x64" / "Debug" / "Release" / "ActiveCfg" / "Build" stuff. Were they able to make it obsolete, or was it moved somewhere else?

[@davidhunter3605]

Great they finally did this. I wonder if it will make having solutions containing both C# and C++ projects work a bit better

[@Petoj87]

This will be a blessing when you get conflicts in the solution file!

[@davepusey]

Unless I happen to add/remove a project, I don't think any of my .sln files have actually changed at all in years.

[@VeNoM0619]

When VS is a 4gb download, I think saving things in 1kb binary is pointless. I wish the .suo was also xmled, so I can just copy and open on multiple computers. Which means I can easily share - last opened files, and breakpoints. Also launch profiles for complex multiproject solutions would be great too,

[@haxi52]

Where did the build configuration info go?

[@jamescomstock7299]

The original solution file you showed had a lot of details about how projects were associated with different builds, but I noted all of that information disappeared. Where did it go? Was it never needed, or did it get moved to a new separate configuration file?

[@nickbarton3191]

What was the significance of the values of the GUIDs?. I always created sln files via the IDE.

[@Thorarin]

Never had to write tooling myself, but this should make merge conflicts less problematic. Often, I just pick one of the files and re-do the changes from the conflicting branch.

[@KennethSiewersMller]

Especially also because most merge-tools (if not all) understand XML.

[@hakanakdag9491]

Great but where are the build options for specific projects?

[@DaminGamerMC]

Something i still dislike is that in Visual Studio you can create a Visual Studio Folder which is not real and only for visualization purposes, but you cant create an actual folder. Will this be fixed?

[@gileee]

If you look closely at the new structure it's just surface level changes. It still says They duplicate the root path, so it's still the same bs, different pair of shoes. But I guess they want to keep compatibility with current projects.

[@efimov90]

Finally, hope configurations will be easy too

[@RonnyLevOr]

When this feature is planned to be released in GA?

[@MrVaradir]

This format should be even more powerful if the right click menu could also physically move/ rename project folders from now on. Like if I had a random pet project without a great name for it, I could easily rename the csproj files directly later. Plus, having the optional feature for the virtual folder structure in the solution to include actual folders/ folder structures, so that I don't have to manually manage the folders in the repo (if that is the requirement)

[@doublebass120]

I’ve rearranged a bunch of solutions in the past, adding solution folders where they weren’t before. It was always a pain because i had to update the path in the sln file. Seems like slnx files would make that task easier.

[@frankhaugen]

I hope this will be the final implementation, looks so nice, and XML will be handled nicely by VCS aswell 🙂

[@FromBeaverton]

Long overdue fix!

[@KennethSiewersMller]

Thanks for the update! I feel like there's missing some additional details of what's possible with the new format? In the current solution format there are all sorts of virtual project sections, build configurations etc. How are those handled in the new format? I'd like to see a followup on that :)

[@daasdingo]

I would argue the current format is a bit too powerful. You already have a filesystem, why stack another abstraction on top?

[@ChaoticNeutral6]

Why is the folder path using Linux convention and the project path using Windows convention?!

[@davepusey]

Those are not real "folder" paths on disk, just the tree-view hierarchy in the Solution Explorer panel.

[@Kitulous]

where are run configurations now I'm wondering... or have they become obsolete and unused?

[@daasdingo]

maybe just the launchSettings.json files?

[@guillaumemichael951]

I am super suprise how fast the solution has been loaded with the XML file, what hardware are you using ??

[@Dimich1993]

The XML solution looks so much better and now I don't have to add styling rules specifically for that old sln mess to my theme for VS Code.

[@cambeyer]

How does User Secrets work with this format? Previously, the path of the secrets file would correspond to the GUID.

[@cn-ml]

Yes, thanks, i love this. This was absolutely the right decision. I hope microsoft continues this feature such that it becomes the default. My concerns are only related to the path separators on different OS.

[@fusedqyou]

Didn't the solution file contain more options? What happened to all that?

[@tymurgubayev4840]

I did write a tool to generate sln files, it's not too complicated, at least in my case.

[@wojciechwilimowski985]

I love when youtubers mention other youtubers

[@lyrion0815]

Try to figure out how to configure Build Configs for projects, if you have more than just "Debug" and "Release". Wonder what that will look like.

[@phizc]

I have created tooling for .sln. Specifically a powershell tool to set up a repository with my defaults. I generate the .sln file since if I just copied it, I would have the same guids for the solution folders at least in all my solutions.. don't know if that would matter, but I decided to generate unique GUIDS instead. Another problem with the old format is that when you create a project, VS will often use one project type, and aome time later, probably when you add another project, it decides the old project type guid was incorrect and changes it, so if you commit the .sln it now looks like there's 2 changes, the added project, and changing the project type of one of the old ones. That's one reason I've been thinking of not including the .sln file in the git repository at all, and just regenerate it whenever it's needed.

[@cjb110]

ok, the project file is simpler but it also contains less information...where's that extra information and settings gone? Is that still easy to access? As the sln was a 'readable' text file even if it was a bit convoluted.

[@karthikbalasubramanya]

Thanks nick...nice feature...

[@GregWilliamBryant]

Epic, Me:Just finished tooling to manage project files! Microsoft: Hold my beer!

[@BudalaHome]

Why it is not in JSON format? Is there any obstacles?

[@patfre]

XML is Microsoft’s JSON it doesn’t have quite as much support but it generally not a big deal

[@gileee]

XML has slightly more expressiveness out of the box with attributes together with values. Although you can solve that with a simple convention (which some already do in json).

[@MichaelBond]

I wonder where all the build and run profiles are stored now, if not in the .slnx file.

[@KibbleWhite]

What was the reason the old sln file were the way they are? Is there any history to that?

[@sergeykichuk2586]

Why do you need to delete projects manually in the solution file ?? I had experience with 125 or more projects in the solution and we didn't have some extraordinary issues with the solution files

[@marcinchilicki3815]

Is it now possible to reorder projects in Solution Explorer using that slnx?

[@Nekroido]

Hmm, I do see this new format doesn't have launch profiles for executable projects yet. Looks hella clean though. Kudos to the team

[@thebilbe]

Why does it need to re-specify "src" if parent node has yet an "/src" attribute value?

[@carldaniel6510]

It's about time. I have many soluitions with 40+ projects and the .sln file is always a mess. Merging changes to the SLN file is a constant source of errors. If I recall correctly, the .sln format dates all the way back to Visual InterDev in 1998(?) and hasn't changed much in all those years.

[@JohanBenschop]

I wonder if solution folders support globbing now with the new slnx format? Already happy not to deal with the rare merge conflict in these files.

[@krss6256]

Great! Finally!

[@stas_kukhar]

Love that🙌🏻

[@dalethompson4466]

So where are the build targets at? (build/debug/any cpu/32-bit/64-bit)

[@dalethompson4466]

oops - I meant to say "(release/debug..."

[@mfsbo]

4:38 save solution as xml for new formar

[@FraserMcLean81]

Nice! I always wondered why solution files were such a hot mess. I wonder how long JetBrains will take to add support to Rider.

[@MalachiMarvin]

What about build configs?

[@sulmarpl]

This is how it should have been from the very beginning. Does CLI dotnet new sln already take into account the new format?

[@ClAddict]

Does slnx support wildcarding?

[@philsnewaddress]

Will this new sln format be valid for older .net framework projects?

[@magnusm4]

This new method is just like HTML. Clean and simple.

[@blgrnboy]

Is it just me, or are the backgrond images that fade into the idea at like 6:14-6:18 comparing a Porsche to a Citroen (not sure, but by first glance, maybe???) lol

[@TheCzemike]

I hope this new SolutionX format is the first step to VS Code supporting .NET Solutions without a separate login to a Visual Studio account.

[@Cornelis1983]

Is there any reason why .csproj and now the new .slnx is using XML and not JSON? I was very happy when web.config with XML was changed to appsettings.json. Why not use json as well for .csproj and .slnx?

[@gileee]

web.config is still there tho. It's where IIS config goes (although no one should use IIS). appsettings.json is only for app configuration.