Absolute or relative paths to .sln no longer works with dotnet sln add

[appel1]

Describe the bug

After upgrading to 9.0.200 adding projects to a solution using dotnet sln add no longer works if the path to the .sln file is a relative or absolute path.

Even with valid paths you get the following 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')

To Reproduce

In the directory, c:\temp\, run the following.

dotnet --version
mkdir build
dotnet new sln -n Converters -o "c:\temp\build\my.sln"
mkdir proj
dotnet new console -o c:\temp\proj
dotnet sln c:\temp\build\my.sln add proj\proj.csproj

After upgrading to 9.0.200 it no longer works:

C:\temp>dotnet --version
9.0.200

C:\temp>mkdir build

C:\temp>dotnet new sln -n Converters -o "c:\temp\build\my.sln"
The template "Solution File" was created successfully.

C:\temp>mkdir proj

C:\temp>dotnet new console -o c:\temp\proj
The template "Console App" was created successfully.

Processing post-creation actions...
Restoring c:\temp\proj\proj.csproj:
Restore succeeded.

C:\temp>dotnet sln c:\temp\build\my.sln add proj\proj.csproj
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')

With earlier SDK versions it succeeded without error:

C:\temp>dotnet --version
9.0.103

C:\temp>mkdir build

C:\temp>dotnet new sln -n Converters -o "c:\temp\build\my.sln"
The template "Solution File" was created successfully.

C:\temp>mkdir proj

C:\temp>dotnet new console -o c:\temp\proj
The template "Console App" was created successfully.

Processing post-creation actions...
Restoring c:\temp\proj\proj.csproj:
Restore succeeded.

C:\temp>dotnet sln c:\temp\build\my.sln add proj\proj.csproj
Project `..\..\proj\proj.csproj` added to the solution.

Exceptions (if any)

Further technical details

C:\temp>dotnet --info
.NET SDK:
 Version:           9.0.200
 Commit:            90e8b202f2
 Workload version:  9.0.200-manifests.e147697c
 MSBuild version:   17.13.8+cbc39bea8

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26100
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.200\

.NET workloads installed:
 [aspire]
   Installation Source: SDK 9.0.200, VS 17.13.35818.85
   Manifest Version:    8.2.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
   Install Type:              Msi

 [wasm-tools]
   Installation Source: SDK 9.0.200, VS 17.13.35818.85
   Manifest Version:    9.0.2/9.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.workload.mono.toolchain.current\9.0.2\WorkloadManifest.json
   Install Type:              Msi

Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.2
  Architecture: x64
  Commit:       80aa709f5d

.NET SDKs installed:
  6.0.202 [C:\Program Files\dotnet\sdk]
  6.0.428 [C:\Program Files\dotnet\sdk]
  7.0.410 [C:\Program Files\dotnet\sdk]
  9.0.200 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.28 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.29 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.28 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.29 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.28 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.29 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[edvilme]

Hello @appel1 We are aware of this regression. It has been fixed in #46456 and should be released in the next servicing release: 9.0.201

[filipvh]

Could this be related to the issue, were if we add a project in our monorepo to the sln file (in the root) that it adds it with a in between structure. We only get it to work as before with adding --solution-folder "/path/to/project", while this was not needed on 9.0.103 Also, it started adding plaforms x86 and x64, while on 9.0.103 it only added "any"

[filipvh]

forgot to mention, but we use dotnet like so

dotnet sln "worspace-name.nx-dotnet.sln" add "packages/apps/the-application-name"

# and after switching from 9.0.103 to 9.0.200 we need to do (any it still does some other stuf different like platforms)

dotnet sln "worspace-name.nx-dotnet.sln" add "packages/apps/the-application-name" --solution-folder "/packages/apps"

[edvilme]

Hello @filipvh. Yes, it is related.
The issue here is that when adding a project without specifying the solution folder, one is created automatically if none are passed as arguments. For the case of projects outside the directory of the solution file, this meant generating solution folder ../foo/.
This caused the command to fail as it would attempt to generate solution folder ...

The upcoming fix makes it so that no solution folders are automatically created when adding a project outside the directory of the solution file. In the meantime, the --solution-foldder "/foo" flag should be a good workaround

[drewnoakes]

We're hitting this in our CI build, a day away from M2 mode.

https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=11072822&view=logs&j=343adee7-d814-546f-dc3f-19ccb8aa9260&t=89b7648e-1790-5d57-056e-699de5ac7dbe

The failing command is:

dotnet sln D:\a_work\1\s\artifacts\Build.sln add "D:\a_work\1\s\src\Microsoft.VisualStudio.ResourceExplorer\Microsoft.VisualStudio.ResourceExplorer.csproj" "D:\a_work\1\s\tests\Microsoft.VisualStudio.ResourceExplorer.Tests\Microsoft.VisualStudio.ResourceExplorer.Tests.csproj" "D:\a_work\1\s\setup\SetupManifest\Setup.csproj"

[edvilme]

Hello @drewnoakes fix is scheduled for 9.0.201 but in the meantime our suggestions could be to either downgrade the sdk version, or to pass in the --solution-folder=foo/bar flag to correctly add the projects

[drewnoakes]

This bug also hit the dotnet/project-system repo. I suspect that a lot of the build logic was copied between these two repositories, explaining why we hit this twice.

We are pinning to the prior version for now. Is a fix still scheduled?

[edvilme]

Hello, this should be working now for 9.0.202