[Discussion] Clean up sln (VisualStudio solution) files #1730
Comments
|
Moving to the msbuild repo where the design for this needs to happen. |
|
This isn't in our power alone, unfortunately. MSBuild is one consumer of the solution format, but arguably not the most important one: Visual Studio itself reads solutions when loading and that code is the canonical copy. This has been put off for almost 15 years now, so I'm pessimistic--but it's a totally reasonable request, and maybe now is the time it can actually get done. Personally, I'd like to see a native MSBuild format rather than a distinct XML schema. But representing all the data in MSBuild could be pretty tricky. |
rainersigwald
added
the
Area: Solution (.sln)
|
+1 for replacing the .sln file with native msbuild files. This probably implies implementing lineup files in one form or another (see lineup files in #1493). And then, probably, also the notion "project cones". |
|
Clearly I'm misunderstanding what the role of the sln file actually is, I thought it was merely for VisualStudio but at build time it would pass the relevant csproj files down to msbuild, and that msbuild only deals with those. But yes, I understand this is not a quick thing to do and requires major efforts across various teams (and companies), but given the effort to simplify csproj files was so well received, we should still strive for it. @rainersigwald do you have a quick example of what an msbuild format for a solution might look like? |
The reason it's more complex than that is that VS builds individual projects with configuration derived from the solution. That enables the things you can do with the Solution Configuration Manager, like "don't build this project in this configuration" or "when the solution is in Release configuration, still build this individual project as Debug". See MSBuild's
I do not, in large part because one of the sources of complexity here is that I don't know all of the configuration capabilities of the .sln format. I learned a new one yesterday investigating #626 (comment)! Building all of the capabilities of the current format into a new one is one reason this has been put off for over a decade (the other big reason is that the solution-handling code in VS is ancient and has tentacles into lots of things, so it's not easy to drop in a replacement).
I agree, and I think everyone agrees in principle--I haven't met defenders of the current format. It's just a matter of prioritization. |
|
As @rainersigwald says, this has been put off repeatedly and it really is something for the VS team to drive as they would do almost all the work (since it's safe to assume they would move to a format that MSBuild already understands) Although the solution has tendrils throughout VS, to my knowledge, knowledge of the solution format is pretty localized (as you would hope) so changing the format should not be a huge effort. Next decision to make would be how VS would handle changing the build process of a solution. Right now you can't do that or at least VS will ignore it: it invokes MSBuild individually on each project in the solution -- it does not "build" the solution itself, as MSBuild does. Lots of parts of VS listen to events through the build of all the projects and if the build process changes, they might get confused about that. (They don't generally pay attention to what happens within the build of a particular project, so this would be a new issue.) However they may want to go further. MSBuild doesn't care what your project structure is, it can be n-level for example. VS doesn't work quite the same when you reference projects that aren't listed in your solution; it doesn't represent visually any kind of hierarchy or structure beyond 2 levels; solution folders are fake folders. So if VS wanted to invest in the solution file, they might want to think beyond just changing the format of the file and instead allow VS to just open any number of random MSBuild files at once and make some sense of it. |
|
+1 for a native MSBuild format. <Project Sdk="Microsoft.Sln.Sdk">
<ItemGroup>
<SolutionProject Include="**\*.*proj" />
</ItemGroup>
</Project> |
|
Since this seems to be more of a long term goal, perhaps in the meantime we can make surgical improvements to the existing format. Can anyone explain/confirm if
|
|
I got exactly the same question, will we have a human-ready sln format? |
|
SLN currently has that archaic syntax. GitHub linguist classifier even doesn't understands it.. was it vb, inf, ruby or which language was the source of inspiration back in 1900-who-knows. Dotnet-cli team had to create a custom parser and writer to add support for XML is something used in proj and working out decently with new format, SLN should be updated. It's now or never!
@danmosemsft, since we don't have any idea whose scones to butter to make it ever happen, but we would stand by you and vote if you further this discussion with right people in VS team. If they just start with the drop-in replacement of SLN for vNext of VS that understands everything what current SLN provides today, it would improve a lot! Once that gets shipped and both VS and MSBuild get familiarized with this format, they can add exciting new features "stuff that wasn't possible with old format". Or VS guys can open source their core solution handling module to enter the community-driven-development bliss. |
ghost
mentioned this issue
|
This idea is listed in the Visual Studio User Voice. Vote for it. |
|
I know that only some of the information is written, depending on the (solution) configuration and platform selected, but the output seen with MSBuildEmitSolution when using MSBuild might be a place to start. Obviously the information in there would need to be generated by the I for one would love there to be something like In the defaults which would allow overriding on a per project basis, and all project metadata to be passed to the project build. And maybe even a nice project globbing pattern based on installed languages / extensions. |
|
I have more use cases here that a MSBuild format would make possible! For example, take a look at MiniProfiler: https://github.com/MiniProfiler/dotnet. It's a library that supports ASP.NET Core and non-Core (new and old) versions. Now because of that, I need sample projects for both. So the solution contains a sample for ASP.NET and a sample for ASP.NET Core, for the people, you know, the lovely people! They like samples. They're good folk. Now, a use case! The If the Plus, ya know, no GUIDs because ewww. |
|
@NickCraver Would something like https://github.com/Microsoft/MSBuildSdks/tree/master/src/Traversal be what you're looking for? Seems like that would be a good model for what solution files should end up being. |
|
I believe in VS organization, the team owning SLN would have more context on full list of supported verbs and variation. Lets assume there is no team, folks who invented SLN two decades ago left and nobody is maintaining it anymore. Then here is a #Hackathon idea for @karelz: Implementation of new format can be done and validated against 3 million SLN files on public GitHub https://github.com/search?q=fileextension%3Asln+project. A cronjob can be written to collect distinct verbs/tokens from 3M files. For parsing, we can use https://github.com/dotnet/cli/blob/b674f5d/src/Microsoft.DotNet.Cli.Sln.Internal/SlnFile.cs. I think if it still misses some obscure verb for example that was only supported in past century VS 97, it is most likely acceptable. With GitHub v3 API, it is bit more work. First it needs to traverse through organizations: Once there is an exhaustive list, an XML schema can be established, which someone in VS team can implement with 5-10 lines of C# code to replace archaic SLN syntax. |
|
@NickCraver a workaround you could use for your case today is to customize MSBuild's view of the solution when it builds from the command line (as in You can do this with a solution build customization. Since your solution is <Project InitialTargets="RemoveIncompatibleProjectsFromDotnetCoreBuild">
<Target Name="RemoveIncompatibleProjectsFromDotnetCoreBuild"
Condition="'$(MSBuildRuntimeType)' == 'Core'">
<ItemGroup>
<!-- These projects don't successfully build in `dotnet build`, so don't build them
when MSBuild is running on Core. -->
<ProjectReferenceToAvoidInDotnetBuild Include="samples\Samples.Mvc5.EFCore\Samples.Mvc5.EFCore.csproj" />
<ProjectReferenceToAvoidInDotnetBuild Include="samples\Samples.Mvc5\Samples.Mvc5.csproj" />
<ProjectReference Remove="@(ProjectReferenceToAvoidInDotnetBuild->'%(FullPath)')" />
</ItemGroup>
</Target>
</Project> |
|
@bording @rainersigwald Thanks! I'll give both of these a look today and see what works. Traversal does seem to be the more appealing option if it works. I'll give it a shot and report back :) |
|
@bording Unfortunately I hit issues with Traversal but indeed that's very appealing. I filed an issue with what I hit; maybe I can help resolve this one given I have an easy (I think) repro: microsoft/MSBuildSdks#34 I'm not sure if this points to a larger issue of tree traversal shenanigans that currently happens via |
|
@NickCraver |
|
A noticeable thing is that if I move a project file's position, project references with GUID will automatically correct its position, seems using GUID from the solution. |
|
@rainersigwald so the last info on this is paraphrased "we're not in charge to decide this" - which is totally fine. But can we at least know who is, maybe a link to uservoice if its directly decided by the VS programm ownership. Also: Maybe we can do this in two steps? Lots of negative feedback for SLN has to do with the large amount of GUIDs in the sln file. Maybe (as the GUID went away from regular projects) we can make an effort to get rid of the GUIDs first and then proceed with the big one in a larger timeframe? |
|
I made an sdk-style msbuild solution file format, the use is limited since there is no VisualStudio support, but it can still be used with vs code, Visual Studio Open Folder or build-only solution. https://github.com/JeffCyr/MSBuild.SolutionSdk A solution file can be as lean as this: <Project Sdk="MSBuild.SolutionSdk/0.0.2" />By default, all csproj/vbproj/fsproj/vcxproj under the folder hierarchy of the solution file will be included in the solution. For simple solutions, the .slnproj file may never have to be edited again. |
|
@JeffCyr there's a ms-built version at https://github.com/Microsoft/MSBuildSdks/tree/master/src/Traversal that does that same you are doing but also covers some more edge cases (but is certainly less user-friendly / documented and lacks default items) <Project Sdk="Microsoft.Build.Traversal/1.0.43">
<ItemGroup>
<ProjectReference Include="src\Common\Common.csproj" />
<ProjectReference Include="src\App\App.csproj" />
<ProjectReference Include="src\WebApplication\WebApplication.csproj" />
</ItemGroup>
</Project> |
|
@dasMulli Indeed, Traversal seems great for creating a simple build script. The main difference with MSBuild.SolutionSdk is that it tries to keep the same experience as current sln files with configuration management and build dependencies. My hope is that this project can serve as a playground to eventually be standardized and replace sln files in Visual Studio. |
|
With the new msbuild Sdk pluggability, the solution proposed above by @JeffCyr and the related MSBuildSDKs/Traversal initiatives are exactly where msbuild sln should go. I would love to see this adopted. There is the IDE integrations story (VS, VSCode, Rider...etc.) but the opportunities/scenarios offered by such a solution (😅) are just tremendously exciting! Is there any plan to prioritize this work? cc: @davkean @KirillOsenkov |
|
XAML? |
Hi, |
|
@workgroupengineering please be specific about what you tried and how it didn't work; there should be no changes in that behavior. |
|
I'm trying to run dotnet-format before the build starts whether it's launched from dotnet cli, visual studio, rider, etc.. . |
|
This is best tracked as a Visual Studio feature suggestion. The best one that I know of is https://developercommunity.visualstudio.com/t/Clean-up-sln-VisualStudio-solution-fil/988209. If Visual Studio changes the solution format, MSBuild would follow. Edit 9/24: Updated link from @chrisaut below that is better. My link https://developercommunity.visualstudio.com/t/Open-MicrosoftBuildTraversal-project-f/1371244 is one possible replacement but not exactly the same. Thanks! |
|
https://developercommunity.visualstudio.com/t/Clean-up-sln-VisualStudio-solution-fil/988209 This is the direct equivalent, as of Aug 9, 2023 it's status has been changed to "On Roadmap" |
You succeeded! https://www.youtube.com/watch?v=wzMMclD8QsI 😉 |
|
Hey @rainersigwald should we change the status of this - or is there another issue tracking it? (couldn't find in search) |
|
See the discussion on Developer Community, though.
|
|
The Microsoft MSBuild team is involved in the internal discussions and trying to guide the effort, and of course MSBuild will adapt to deal with what what we settle on, but that's not quite set yet so no additional concrete MSBuild work. |
|
I agree with @xoofx that being able to express dependencies via msbuild conditions is something that we need. Many of our own repositories would immensely benefit from this, especially the VMR effort. |
|
i'm just glad that guids are gone which fixes long standing issues like dotnet/project-system#1821 |
|
@rainersigwald, thank you for the update. I have to admit that I don't have details about why |
That detail is not relevant to MSBuild; it helps Visual Studio decide which project system to initialize for the specific projects (there are two, https://github.com/dotnet/project-system and an older closed-source one that's used for non-.NET-SDK projects). |
Why is that attribute even required? VS should be able to read the first line (or few lines) and determine which project system to use right? |
I believe it's not possible to correctly handle every case without do a full xml deserialization, or even loading a full MSBuild to evaluate it. MSBuild projects are quite flexibie. |
But what's strange is I created a slnx from a solution (.NET 8 Avalonia projects + xUnit). It wrote all projects without the attribute, except the xUnit one which had "Classic C#". I removed that attribute and it still worked without difference. Another thing I noticed globbing (*.csproj or for solution items) did not work. |
Please submit this kind of feedback to the VS team via VS Feedback! |
|
Hey folks, I'm the VS team. The "Classic C#" is just a point in time issue and we'll fix this in a future update to the format. This is a similar case to what's called out on dotnet/project-system#1821, but we've come up with a solution to resolve this. |
We are very interested in this but only as a dotnet feature not as a Visual Studio-specific feature. slnx is currently supported in Visual Studio but not Visual Studio for Mac and not Rider. This implies that slnx doesn't work in cross-platform projects. The current Rider status is https://youtrack.jetbrains.com/issue/RIDER-110777 from a month ago:
Can I ask therefore: is this format now documented and communicated to developers of clients other than VS? |
is retiring in august https://learn.microsoft.com/en-us/visualstudio/mac/what-happened-to-vs-for-mac |
|
It's a positive change, but at the same time a disappointing one. (See announcement.) It seems that Microsoft has decided not to turn the solution file into a proper MsBuild file, but instead invented a specific XML format for the solution file. |
|
if slnx parser in visual studio is using dotnet, it can depend on msbuild evaluation engine package for flip side is dumb solution files (as they ever were) keep parser implementation efficient and user expectations in check |
The feature is highly incomplete and work in progress. We still need to wait for some time for announcement of it. |
|
I only ask myself one simple question: How can a feature not be implemented after 20 YEARS of the community continually asking for it? |
and others
From @chrisaut on February 21, 2017 4:32
Now that the csproj files are
somewhatclean, are there plans to similarly clean up .sln files?A sample solution with just two projects looks like this today:
I see 3 "sections":
1) Information about VS, which version created it and the minimum version
2) List or projects and their locations
3) Solution and ProjectConfigurationPlatforms
Is the VisualStudio stuff really needed? I regularly run into changes here when opening solutions in different versions, it creates a change for no apparent reason.
Can we get rid of the GUIDs for the project lists? Also the logical name (coreDemo, netStdLib) in addition to the csproj, can this just be infered for the probably 99.99% case when the two match?
I can't say much about the ConfigurationPlatform stuff, except that it looks messy. I feel like this should be pulled out somehow.
Since everything is going xml (....I know, I know), perhaps the format of the sln file should also be xml.
A minimalistic solution could look something like this:
A few things to note:
The Project Type Guids ("FAE04EC0-301F-11D3-BF4B-00C04F79EFBC", at least that's what I think those are) are messy, if this is really needed by VS for some reason let's please make it a string that makes sense for humans ("netCoreConsole" in the example).
We pull the ProjectConfigurations into the projects where they logically belong. Also, while at times custom platform/configurations are needed, most of the time people I think just use the default (x86/x64/Any CPU)/(Debug/Release).
So we just make those the default.
For the project list we could also do the filepattern thing (**/*.csproj) but I feel like projects aren't added/removed often enough to warrant this, so perhaps being explicit here is the better choice.
I just want to start this issue so that a discussion can be started, I'm by no means an expert on this stuff.
Copied from original issue: dotnet/project-system#1594
The text was updated successfully, but these errors were encountered: