You Need to Update Your .NET Solution Files!

Until the 21st of April, buy ANY Dometrain course and get the From Zero to Hero - LINQ in .NET course for free!! dometrain.com/courses/
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this video I will introduce you to the new Solution Format that is coming with the latest Visual Studio Preview. This new format is called .slnx and it is a simple XML format to replace the old nightmare of .sln files.
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elfocrash
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet

[@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 😆

[@andersborum9267]

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.

[@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.

[@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.

[@SergeyPogreban]

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

[@krccmsitp2884]

As sub-elements, not shown in this video.

[@eye776]

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

[@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.

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

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

[@dalemac89]

​@chris-pee actually, there is a new solution level startup project configuration selection in preview 17.10 as well. Even better, it saves to a settings file (I forgot the name but it's similar to how launchsettings.json works) so it can be committed to a repository, so new contributors don't have to manually change the startup projects.

[@chris-pee]

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

[@p.j.wilkins1321]

Definitely an interesting look at Quirks and Features.

[@TuxCommander]

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

[@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...

[@delpher1983]

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

[@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.

[@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.

[@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.

[@meirkr]

Very good improvement. I propose naming the extension .slnx

[@safalin1]

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

[@davidhunter3605]

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

[@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.

[@JamesHarrisonHaribo]

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.

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

[@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.

[@karthikbalasubramanya]

Thanks nick...nice feature...

[@ivanp_personal]

I like this new XML solution format. Great improvement.

[@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?

[@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.

[@nove1398]

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

[@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!

[@AJax2012]

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

[@user-zp3th3tj8k]

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?

[@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.

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

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

[@Petoj87]

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

[@PatricSjoeoe]

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

[@yoanashih761]

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

[@KeesAlderliesten]

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

[@efimov90]

Finally, hope configurations will be easy too

[@FromBeaverton]

Long overdue fix!

[@frankhaugen]

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

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

[@SG_01]

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

[@stas_kukhar]

Love that🙌🏻

[@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.

[@magnusm4]

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

[@krss6256]

Great! Finally!

[@SamuelSidor]

beautiful

[@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.

[@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?

[@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?

[@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.

[@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.

[@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.

[@Aaron31056]

Wow nice!

[@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.

[@CricketThomas]

You should be using the new redesign of VS2022!

[@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.

[@tymurgubayev4840]

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

[@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)

[@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.

[@nickbarton3191]

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

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

[@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.

[@haxi52]

Where did the build configuration info go?

[@thedreadedgman]

finally... just took 20+ years... now we just need it to be implemented... damn

[@mortenmoulder]

Isn't the project name stored in the solution file? It's not in the new one.. or am I missing something?

[@marcinchilicki3815]

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

[@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?

[@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.

[@wojciechwilimowski985]

I love when youtubers mention other youtubers

[@Sander-Brilman]

This is awesome, love the format

[@RonnyLevOr]

When this feature is planned to be released in GA?

[@classiccomputing]

FINALLY!!!

[@philsnewaddress]

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

[@carlosmunozrodriguez]

Finally!!!

[@dcuccia]

THIS is the way.

[@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.

[@egorshiyanov1206]

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

[@baxalasse]

Does anyone know if there are any loading performance gains to the new format?

[@MichaelBond]

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

[@evanAmazing]

Does anyone know if this is specific to .NET solutions, or is the plan that this will replace the standard .sln file for all types of projects?

[@Bennevisie]

Anyone know when this will be supported in Rider?

[@Tony-dp1rl]

Probably due to improving the vs.code features and experience.

[@dimasikkalibis9248]

Awesome!!!

[@hakanakdag9491]

Great but where are the build options for specific projects?

[@ClAddict]

Does slnx support wildcarding?

[@MalachiMarvin]

What about build configs?

[@tiendatniit]

Nice. IT's really easy to read haha

[@juliandave3648]

Is it possible to create the new solution with vscode?

[@thebilbe]

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

[@Jasonlhy]

Does it also work for C++ project ?

[@krccmsitp2884]

Finally!

[@KibbleWhite]

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

[@guillaumemichael951]

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