sln-add: Support for slnx

[edvilme]

Contributes to #40913

The dotnet CLI should support the new slnx format for building and in the existing solution management commands. It should also help interested users migrate to the new format.

This adds dotnet sln add support for .slnx files

[kasperk81]

@edvilme checkout the complete feedback. using solution.FindProject makes the regex usage irrelevant

[kasperk81]

The dotnet sln add command should avoid generating project GUIDs for .slnx files because .slnx is a path-based format.

• When the project file contains <ProjectGuid>:

  • Include the GUID in .slnx, but ensure it is in uppercase.
  • Currently, .slnx uses lowercase GUIDs, while .sln uses uppercase. This inconsistency should be resolved.

• When <ProjectGuid> is absent:

  • Use the default path-based format without including any GUID (Id) in the .slnx entry.

The current behavior auto-generates GUIDs and inserts them in entries like <Project Path="{path}" Id="{guid}" />. This is unnecessary because GUIDs are optional in .slnx, intended only for legacy support. The path-based format was specifically requested by developers for over 10 years (see this discussion: dotnet/msbuild#1730). Visual Studio developers eventually implemented the .slnx format to support path-based solutions without forcing GUIDs.

In short, the SDK should not force GUIDs when the community prefers the cleaner, GUID-free path-based approach.

[edvilme]

/backport to release/9.0.2xx

[github-actions]

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

[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: [IMP] sln-list: Support for slnx
Using index info to reconstruct a base tree...
M	src/Cli/dotnet/commands/dotnet-sln/LocalizableStrings.resx
M	src/Cli/dotnet/commands/dotnet-sln/list/Program.cs
M	src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.cs.xlf
M	src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.de.xlf
M	src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.es.xlf
M	src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.fr.xlf
M	src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.it.xlf
M	src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.ja.xlf
M	src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.ko.xlf
M	src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.pl.xlf
M	src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.pt-BR.xlf
M	src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.ru.xlf
M	src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.tr.xlf
M	src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.zh-Hans.xlf
M	src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.zh-Hant.xlf
Falling back to patching base and 3-way merge...
Auto-merging src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.zh-Hant.xlf
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.zh-Hant.xlf
Auto-merging src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.zh-Hans.xlf
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.zh-Hans.xlf
Auto-merging src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.tr.xlf
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.tr.xlf
Auto-merging src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.ru.xlf
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.ru.xlf
Auto-merging src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.pt-BR.xlf
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.pt-BR.xlf
Auto-merging src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.pl.xlf
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.pl.xlf
Auto-merging src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.ko.xlf
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.ko.xlf
Auto-merging src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.ja.xlf
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.ja.xlf
Auto-merging src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.it.xlf
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.it.xlf
Auto-merging src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.fr.xlf
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.fr.xlf
Auto-merging src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.es.xlf
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.es.xlf
Auto-merging src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.de.xlf
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.de.xlf
Auto-merging src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.cs.xlf
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/xlf/LocalizableStrings.cs.xlf
Auto-merging src/Cli/dotnet/commands/dotnet-sln/list/Program.cs
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/list/Program.cs
Auto-merging src/Cli/dotnet/commands/dotnet-sln/LocalizableStrings.resx
CONFLICT (content): Merge conflict in src/Cli/dotnet/commands/dotnet-sln/LocalizableStrings.resx
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 [IMP] sln-list: Support for slnx
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

[Bartleby2718]

@edvilme @kasperk81 @nagilson @baronfel @Forgind I'm thinking of picking up #45072 again, but I want to make sure we're aligned on the approach.

First, my personal preferences:

1. I prefer using giving descriptive variable names and using the latest syntax (e.g. collection expressions).
2. I prefer small, incremental PRs as they are easier to understand and review.

Problems for each:

1. These style changes can be distracting for reviewers.
2. A lot of PRs get merged to this repository, so merge conflicts (e.g. in resx files) can happen, which isn't the end of the world but can be annoying for me to resolve.

Do you want a big PR (like #45072 currently is) that includes style changes, or do you want a few small PRs (perhaps with style/resx changes coming first)?

[edvilme]

Hello @Bartleby2718
Firstly thanks for your interest in this, I believe this will be very useful functionality.

Regarding the PRs I agree that atomic PRs might be easier to review and develop than massive PRs. However my personal suggestion would be to find something in the middle and making sure those are independent, as to avoid having a lot of merge conflicts, backports and reviews on different PRs.
I would recommend maybe creating different PRs dotnet sln add folder, and dotnet sln add file as they would be independent functionalities.

As for the style, whatever works best for you, but due to the size of the repo, I would suggest attaching to the code conventions used as it makes it easier to maintain and contribute to in the future.

[jurakovic]

Im on Windows, using Git Bash, dotnet version 9.0.200.

When I execute this:

dotnet sln Some.Solution.sln add ../Some.Project/src/Some.Project/Some.Project.csproj

I get this error

Names cannot:
- contain any of the following characters: / ? : \ * " < > |
- contain control characters
- be system reserved names, including 'CON', 'AUX', 'PRN', 'COM1' or 'LPT2'
- be '.' or '..' (Parameter 'name')

Is this expected behavior? Because using Visual Studio I can normally add project like that.

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Some.Project", "..\Some.Project\src\Some.Project\Some.Project.csproj", "{4075164D-23CE-C114-6999-4E73B7467650}"

This worked fine until I have updated VS do 17.13.0 today.
I have a lot of solutions and projects and some scripts that automated process of adding projects to solutions, but all of that doesn't work now.

How can I add project with path starting with ".." using cli?

[kasperk81]

yea dotnet sln add ../foo.csproj is working in 9.0.102 and failing with "Names cannot:" error in 9.0.200

[kasperk81]

- contain any of the following characters: / ? : \ * " < > |

this error message is incorrect

dotnet sln add subdirectory/foo.csproj

works and / has no problem. it only doesn't like ..

[edvilme]

Hello @kasperk81 @jurakovic thanks for reaching out. Yes, we are aware of this bug when adding projects outside the solution file directory (and descendants) and already have a fix #46456 that should be released with 9.0.201

[jurakovic]

@edvilme how can I rollback to SDK 9.0.102?

If I try to uninstall it using "Add or Remove Programs" I get this message

If I try to remove it using VS Installer it says it will also remove all related components, but that's certainly something I don't want to.

Are there any other options or workarounds?
Thank you in advance

[philipp-naused]

@jurakovic You don't need to remove 9.0.200. You can install multiple versions of the SDK in parallel.
https://dotnet.microsoft.com/en-us/download/dotnet/9.0
Add a global.json file to the root of your repo like this:

{
  "sdk": {
    "version": "9.0.102",
    "rollForward": "disable"
  }
}