[ADD] dotnet solution migrate

[edvilme]

Created dotnet solution migrate solutionfile.sln to generate a new solution file with the .slnx extension using https://github.com/microsoft/vs-solutionpersistence

Contributes to #40913 (dotnet sln migrate)

[kasperk81]

unit tests upcoming?

Addresses #40913

I thought addressing that epic also includes:

• dotnet new solution --format slnx (with alias -f slnx)
• dotnet sln {add,remove,list} my.slnx my.csproj commands

[edvilme]

unit tests upcoming?

Hello. Yes, this is still WIP and will have a unit test that verifies if the command work. Additional testing on how the conversion is done, is more related to the https://github.com/microsoft/vs-solutionpersistence project as we just consume their API

[kasperk81]

btw, current main and 9.0.200 branch can "build" .slnx #40913 (comment), so the test can assert on that to cover migration.

you may also consider changing Addresses #40913 to Contributes to #40913 so it doesn't close the issue on merge for additional work (dotnet new sln, dotnet sln {add,remove,list} my.slnx my.csproj), and keep this PR for dotnet sln migrate only.

[nagilson]

The change looks good so far :) I've left some thoughts below. Definitely add some tests like mentioned above. Also, please keep the PR in a draft state if it's still a WIP so it's clear to reviewers.

[just-ero]

Hi, I just want to make sure: this command won't require the solution path to be provided, right? It will take the solution file present in the current directory if no path is specified?

After migrating (I feel like convert would have been a nicer name), does the original solution file get deleted? Renamed? Does it stay?

[nagilson]

@just-ero raises a great point, many of our commands work if there is only one sln or project file in the directory where you don't need to specify a project or sln to take action on. Some of them even work if there are multiple and just picks one based on some order, like so:

string? potentialSln = Directory.GetFiles(arg, "*.sln", SearchOption.TopDirectoryOnly).FirstOrDefault();

I don't think this was in the original spec but we should support that. I am very familiar with the code to do that, so if you have questions let me know :)

[nagilson]

After migrating (I feel like convert would have been a nicer name), does the original solution file get deleted? Renamed? Does it stay?

@baronfel? I prefer 'migrate' personally and would keep the original solution file, deleting the file may be unexpected and cause pain there but it could be an option to provide.

[edvilme]

After migrating (I feel like convert would have been a nicer name), does the original solution file get deleted? Renamed? Does it stay?

@baronfel? I prefer 'migrate' personally and would keep the original solution file, deleting the file may be unexpected and cause pain there but it could be an option to provide.

I also prefer migrate and definitely think we should keep the original solution file at least until the rest of the dotnet sln commands are ready. Otherwise people would run the command with no way of undoing it and things could get messy (?)

I would advocate towards having a --replace flag and additional confirmation from the user if that was the path we wanted to follow

[just-ero]

string? potentialSln = Directory.GetFiles(arg, "*.sln", SearchOption.TopDirectoryOnly).FirstOrDefault();

Maybe this command should panic when more than one solution file is found?

[baronfel]

I've added details to the migration section on the linked issue. We should not delete the pre-existing .sln file, users are free to do that once they have tested and verified the slnx. solves their needs. We should use our existing solution-discovery mechanisms like we do for the other dotnet sln commands. We should error out if there are multiple .sln files in a directory that is used and no explicit sln argument is provided.

[nagilson]

string? potentialSln = Directory.GetFiles(arg, "*.sln", SearchOption.TopDirectoryOnly).FirstOrDefault();

Maybe this command should panic when more than one solution file is found?

That is not how other commands behave, so I think its good to be consistent. This is the logic used by other commands.

[edvilme]

Hello @dotnet/product-construction I am trying to add package vs-solutionpersistence but got a strong name error. Is this already signed? Or should I be doing it differently?

CC: @surayya-MS

[kasperk81]

to unblock, we can add this line to dotnet.csproj

sdk/src/Containers/Microsoft.NET.Build.Containers/Microsoft.NET.Build.Containers.csproj

Line 20 in 3b653cc

<NoWarn>$(NoWarn);CS8002</NoWarn>

[edvilme]

to unblock, we can add this line to dotnet.csproj

sdk/src/Containers/Microsoft.NET.Build.Containers/Microsoft.NET.Build.Containers.csproj

Line 20 in 3b653cc

<NoWarn>$(NoWarn);CS8002</NoWarn>

I wouldn't choose to do that as that would not address the issue but mostly mask it, and could potentially cause issues in the future

[kasperk81]

you mean there are potential issues with Microsoft.NET.Build.Containers 1.3M downloads https://www.nuget.org/packages/Microsoft.NET.Build.Containers/8.0.403? ok, if you say so..

[kasperk81]

microsoft/vs-solutionpersistence#68

[nagilson]

This is almost ready 🔥 I am so excited for this to go in, and I think a lot of people are :) Great work so far, the code looks clean. I have one more concern / comment, after that I think we can merge this.

[nagilson]

Well done, excited to see this go into the SDK 👏

I think we can merge this, but I would still suggest to have the API owner look over the call as well as mentioned above.

[edvilme]

Hello @dotnet/source-build @richardstanton can I please get some help on the Strong Name requirement for Microsoft.VisualStudio.SolutionPersistence? Thx!

[richardstanton]

Hello @dotnet/source-build @richardstanton can I please get some help on the Strong Name requirement for Microsoft.VisualStudio.SolutionPersistence? Thx!

My understanding was that strong naming was generally deprecated in .NET Core as it is ignored in assembly loading. (https://github.com/dotnet/runtime/blob/main/docs/project/strong-name-signing.md) So it wasn't a priority when adding to source-build. (Note, the dll should still be authenticode signed which is important)

The dll built for the NuGet package is strong named signed, partially because it is built with the .NET Framework version that requires this, but also because it is built with a very different pipeline than source-build.

It seems like suppressing the warning might be ok if everything is .NET Core.

[ellahathaway]

Hello @dotnet/source-build @richardstanton can I please get some help on the Strong Name requirement for Microsoft.VisualStudio.SolutionPersistence? Thx!

My understanding was that strong naming was generally deprecated in .NET Core as it is ignored in assembly loading. (https://github.com/dotnet/runtime/blob/main/docs/project/strong-name-signing.md) So it wasn't a priority when adding to source-build. (Note, the dll should still be authenticode signed which is important)

The dll built for the NuGet package is strong named signed, partially because it is built with the .NET Framework version that requires this, but also because it is built with a very different pipeline than source-build.

It seems like suppressing the warning might be ok if everything is .NET Core.

Agreed that the suppressing the warning is the way to go here.

[nagilson]

Looks good! I would check with @marcpopMSFT to see if we still have time to get this into 9.0.2xx and if there's any process to do so. (that was the goal, correct @baronfel?) Right now, this is targeting main, so this one you can merge regardless.

[edvilme]

/backport to release/9.0.2xx

[github-actions]

Started backporting to release/9.0.2xx: https://github.com/dotnet/sdk/actions/runs/12204682295

[github-actions]

@edvilme backporting to release/9.0.2xx failed, the patch most likely resulted in conflicts:

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch

Applying: [ADD] dotnet sln: Migrate
Using index info to reconstruct a base tree...
M	Directory.Packages.props
M	src/Cli/dotnet/dotnet.csproj
Falling back to patching base and 3-way merge...
Auto-merging src/Cli/dotnet/dotnet.csproj
CONFLICT (content): Merge conflict in src/Cli/dotnet/dotnet.csproj
Auto-merging Directory.Packages.props
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 [ADD] dotnet sln: Migrate
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!