You Need to Update Your .NET Solution Files!
2024 ж. 10 Сәу.
72 042 Рет қаралды
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
Finally. The original format looked like the Visual Basic team made it
They probably did
Jajaja
I was thinking the same 😆
Yeah, just before the first developer left and the rest of the team took over .. and kept it.
Just in time for me as I am about to retire
Old sln files are a nightmare when resolving GIT conflicts
Indeed. But understanding them has made me look good over the years lol
hallelujah. getting merge conflicts in sln files was such a pain
Merge conflicts nightmare? A dream now. Love it.
@@IIARROWS have you ever managed thousand lines of XML files?
"LINQ in the description"
Doug is last person I expected to pop out in THIS video
Nick shows us AHLLLL the QUIRKS and FEATURES of .Net.
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.
TIP: Enter '*' for the filename in the project/solution file picker dialog and you can choose the slnx-file too. :-)
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.
How about build configurations? Where will the configurations be stored with new solution format?
As sub-elements, not shown in this video.
There's a class for parsing solution files: Microsoft.Build.Construction.SolutionFile
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.
I suspect the startup project is an IDE-specific config, which they're trying to avoid in the new format.
@@chris-pee Good point
@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.
@@dalemac89 yeah that sounds like a proper solution (pun not intended)
They need to make is easy to view the .slnx (and .sln) files from within Visual Studio
I agree, You shouldn't have to switch to folder view to open them within VS.
@@KotyBashfordyeah, and solution level directory.packages.props files for centralised package management.
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
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.
Nice, finally setting up a my planned Builder project becomes more handy with this.
Definitely an interesting look at Quirks and Features.
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...
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.
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.
So how it looks when build config is changed? (e.g. exclude project build from release config) Old format contained this, too.
Would love to get to know this too
I think it won't be a problem to configure it with XML, it will be even more intuitive
Probably with XML conditionals
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
That's a really good question
Would like to see how explicitly entered build dependencies and build configurations show up in the new format. Is there a specification available already?
This is a million times better. Glad it's finally getting updated - no more hassle with merges!
Long overdue fix!
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?
Aren't configurations loaded from each .csproj file now anyway. Like, Debug;Release And then you do DEBUG;TRACE ...
@@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.
@@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.
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.
You can look at solution filters.
It's just standard XML, so the usual comments should work.
I like this new XML solution format. Great improvement.
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.
Great they finally did this. I wonder if it will make having solutions containing both C# and C++ projects work a bit better
When you said "This", I thought it was KZhead bug as recently I am watching car reviews a lot and thought KZhead just uses my history :) It was very interesting feature though.
Very good improvement. I propose naming the extension .slnx
The preview features are directly in the Tools menu.. 'Manage Preview Features', 2nd from the top..
Finally, hope configurations will be easy too
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
I'm curious why Microsoft hasn't opted for JSON or YAML as the format for their project/solution configuration files.
This will be a blessing when you get conflicts in the solution file!
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.
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.
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 :)
I would argue the current format is a bit too powerful. You already have a filesystem, why stack another abstraction on top?
This looks much better, I accidentally wrecked my project by messing with the .sln file before. Had no idea what i was doing
uuugh, finnally. I can't believe it took this long to fix the solution files to be more readable. Looks amazing.
Finally! :) If you have 30+ projects, this file is crazy 😂
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?
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!
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.
agreed. That was really nice. Even for csproj with the version inline editing/autocompletion was amazing.
Solution files are MsBuild files and MsBuild always used xml
I hope this will be the final implementation, looks so nice, and XML will be handled nicely by VCS aswell 🙂
Love that🙌🏻
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.
Especially also because most merge-tools (if not all) understand XML.
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.
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.
@@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.
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.
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.
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.
There are things like this, with which MS gets late not by years, by decades! But finally it is here. We can celebrate 🎉
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.
Nice! I always wondered why solution files were such a hot mess. I wonder how long JetBrains will take to add support to Rider.
beautiful
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.
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
You should be using the new redesign of VS2022!
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.
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.
Solution files are downright ancient, it's good to see them getting a makeover.
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)
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,
Hmm, I do see this new format doesn't have launch profiles for executable projects yet. Looks hella clean though. Kudos to the team
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.
I did write a tool to generate sln files, it's not too complicated, at least in my case.
I love when youtubers mention other youtubers
Great! Finally!
Will this feature come to dotnet CLI? Great to see that sln files are starting to look similar to csproj files 🎉
Why is the folder path using Linux convention and the project path using Windows convention?!
Those are not real "folder" paths on disk, just the tree-view hierarchy in the Solution Explorer panel.
Where did the build configuration info go?
I wonder where all the build and run profiles are stored now, if not in the .slnx file.
Great but where are the build options for specific projects?
Will this new sln format be valid for older .net framework projects?
I think a more accurate title would be "You Will Need to Update Your .NET Solution Files Once This Feature Is Released"
where are run configurations now I'm wondering... or have they become obsolete and unused?
maybe just the launchSettings.json files?
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?
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?
@Nick Chapsas can you please investigate resource usage by mediatr for simple API (with and without mediatr). What % of resources will be eaten for each request/response and in total. It's interesting for customers. We pay money for each IO in cloud and if we can optimize this area it will be cool) Thanks in advance! Actually it's a huge area for new videos - how to save money :)
What about build configs?
But how are configurations handled?
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.
This new method is just like HTML. Clean and simple.
How does User Secrets work with this format? Previously, the path of the secrets file would correspond to the GUID.
Does it work with .NET framework and MSBUILD?
What was the significance of the values of the GUIDs?. I always created sln files via the IDE.
Finally!!!
When this feature is planned to be released in GA?
FINALLY!!!
"Please not JSON." "Please not JSON." "Please not JSON." "Phew, thankfully it's XML."
I am super suprise how fast the solution has been loaded with the XML file, what hardware are you using ??
Love the Doug references 😂
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?
So where are the build targets at? (build/debug/any cpu/32-bit/64-bit)
oops - I meant to say "(release/debug..."
Isn't the project name stored in the solution file? It's not in the new one.. or am I missing something?
Is there feature only for vs or for rider also will be available ?
I'm pretty sure JetBrains will follow up with this in one of the coming 2024.2 EAP releases, but currently, it's not supported.
@@KennethSiewersMller For sure. I think the same.
Probably due to improving the vs.code features and experience.
Is it now possible to reorder projects in Solution Explorer using that slnx?
Wow nice!
I don't like to run into git merge conflicts with the current solution format, it's very sad. Glad they finally switched to something that makes more sense
Epic, Me:Just finished tooling to manage project files! Microsoft: Hold my beer!