You Need to Update Your .NET Solution Files!
HTML-код
- Опубликовано: 10 апр 2024
- 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"
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. :-)
Doug is last person I expected to pop out in THIS video
Nick shows us AHLLLL the QUIRKS and FEATURES of .Net.
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.
There's a class for parsing solution files: Microsoft.Build.Construction.SolutionFile
How about build configurations? Where will the configurations be stored with new solution format?
As sub-elements, not shown in this video.
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
There are things like this, with which MS gets late not by years, by decades! But finally it is here. We can celebrate 🎉
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.
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)
Definitely an interesting look at Quirks and Features.
Nice, finally setting up a my planned Builder project becomes more handy with this.
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...
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.
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.
Very good improvement. I propose naming the extension .slnx
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.
When you said "This", I thought it was RUclips bug as recently I am watching car reviews a lot and thought RUclips just uses my history :)
It was very interesting feature though.
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.
This is a million times better. Glad it's finally getting updated - no more hassle with merges!
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.
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
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
uuugh, finnally. I can't believe it took this long to fix the solution files to be more readable. Looks amazing.
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.
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
Would like to see how explicitly entered build dependencies and build configurations show up in the new format.
Is there a specification available already?
I like this new XML solution format. Great improvement.
Finally! :)
If you have 30+ projects, this file is crazy 😂
I'm curious why Microsoft hasn't opted for JSON or YAML as the format for their project/solution configuration files.
Solution files are downright ancient, it's good to see them getting a makeover.
This will be a blessing when you get conflicts in the solution file!
Thanks nick...nice feature...
This looks much better, I accidentally wrecked my project by messing with the .sln file before. Had no idea what i was doing
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
Hmm, I do see this new format doesn't have launch profiles for executable projects yet. Looks hella clean though. Kudos to the team
This new method is just like HTML.
Clean and simple.
Long overdue fix!
Finally, hope configurations will be easy too
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.
I hope this will be the final implementation, looks so nice, and XML will be handled nicely by VCS aswell 🙂
The preview features are directly in the Tools menu.. 'Manage Preview Features', 2nd from the top..
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.
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.
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?
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?
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.
Love that🙌🏻
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.
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)
Great! Finally!
beautiful
I love when youtubers mention other youtubers
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.
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.
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.
finally... just took 20+ years... now we just need it to be implemented... damn
Wow nice!
I did write a tool to generate sln files, it's not too complicated, at least in my case.
You should be using the new redesign of VS2022!
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.
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.
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
Love the Doug references 😂
This is awesome, love the format
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
Finally!!!
THIS is the way.
Finally!!!! Now we can say goodbye to solution merge conflicts!!! But the question stays: Why did Microsoft use that atrocious solution format early? It was a pain in the ass when multiple devs work on the same solution adding new projects, moving or removing others, etc...
As the sln format is hard, we decided to just scan the folder structure to find all csproj files in a particular solution. Which obviously is not perfect. With this new solution format it can be finally be done correctly easily!
@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 :)
I wonder where all the build and run profiles are stored now, if not in the .slnx file.
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?
"Please not JSON." "Please not JSON." "Please not JSON."
"Phew, thankfully it's XML."
Epic,
Me:Just finished tooling to manage project files!
Microsoft: Hold my beer!
FINALLY!!!
First of all, thanks for the info and for the video! But please remove that flickering from the top of the video because it really makes the eyes flickering too. :P
It took them 2 freaking decades!
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,
Nice. IT's really easy to read haha
Where did the build configuration info go?
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.
I just hope they make it feature complete by the time this goes live. Any feature that exists in sln needs to be in slnx before they call it done - or else be very clearly documented as a retired feature.
I would hate to see necessary features missing, or a “use the new format unless you need support for TFS integration, but only pre-2020 versions, unless you have SP2 but not SP3, or if you have an enterprise license and authenticate to your machine using domain credentials with a 16+ character password that doesn’t contain the letter “w”.
Great but where are the build options for specific projects?
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.
Nice improvement, but why do they insist with XML files when JSON or even YAML files are so much more readable and less verbose? To me everything should be JSON or YAML, including XAML files.
Will this feature come to dotnet CLI? Great to see that sln files are starting to look similar to csproj files 🎉
FINALLY OH MY GOD. I just went on a roller coaster where I had to remove an old x86 configuration from about 30 projects in a solution and it was an absolute NIGHTMARE. It took me hours to do a job that should have been either one button in the UI or a few lines deleted from the solution file
What was the significance of the values of the GUIDs?. I always created sln files via the IDE.
Probably due to improving the vs.code features and experience.
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?
Finally!