dotnet
Absolute or relative paths to .sln no longer works with `dotnet sln add`
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
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.
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.
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
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"
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"
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
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"
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
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?
Reopening and sending back to triage as this seems to still be occurring in 9.0.300-preview.0.25177.5.
From this build log:
dotnet --info output
dotnet --info
.NET SDK:
Version: 9.0.300-preview.0.25177.5
Commit: 3d5b396331
Workload version: 9.0.300-manifests.1e5233e8
MSBuild version: 17.14.0-preview-25175-08+5880e1c75
Runtime Environment:
OS Name: Windows
OS Version: 10.0.20348
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.300-preview.0.25177.5\
.NET workloads installed:
[maui-windows]
Installation Source: VS 17.14.36017.23
Manifest Version: 9.0.14/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maui\9.0.14\WorkloadManifest.json
Install Type: Msi
[maccatalyst]
Installation Source: VS 17.14.36017.23
Manifest Version: 18.4.9288/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maccatalyst\18.4.9288\WorkloadManifest.json
Install Type: Msi
[ios]
Installation Source: VS 17.14.36017.23
Manifest Version: 18.4.9288/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.ios\18.4.9288\WorkloadManifest.json
Install Type: Msi
dotnet new sln -n Build -o D:\a\_work\1\s\artifacts\ --force
The template "Solution File" was created successfully.
dotnet sln Build.sln add "D:\a\_work\1\s\src\Microsoft.VisualStudio.ProjectSystem.Managed.VS\Microsoft.VisualStudio.ProjectSystem.Managed.VS.csproj" --solution-folder="D:\a\_work\1\s\artifacts\"
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')
1>D:\a\_work\1\s\eng\Build.proj(57,5): error MSB3073: The command "dotnet sln Build.sln add "D:\a\_work\1\s\src\Microsoft.VisualStudio.ProjectSystem.Managed.VS\Microsoft.VisualStudio.ProjectSystem.Managed.VS.csproj" --solution-folder="D:\a\_work\1\s\artifacts\"" exited with code 1.
1>Done Building Project "D:\a\_work\1\s\eng\Build.proj" (default targets) -- FAILED.
Unlike @filipvh above, the paths here are absolute Windows paths that include a drive identifier. Perhaps that is being used as whatever is trying to create a "name" containing one of the invalid characters: / ? : \ * " < > |
Can confirm that the issue is caused by having a drive letter in the paths. Making everything relative makes the issue go away.
For me there is also bug or change in behaviour when passing list of projects - before change in SDK proper solution was created (projects was in same subfolders like in folders on disk) but now it looks like all projects are inserted to the first subfolder that is created (I'm not exactly sure what is the logic). My workaround is to group my list of projects per subdirectory and add them separately but I don't know why this behaviour was changed
Reopening and sending back to triage as this seems to still be occurring in 9.0.300-preview.0.25177.5.
From this build log:
dotnet --info output
dotnet new sln -n Build -o D:\a\_work\1\s\artifacts\ --force The template "Solution File" was created successfully. dotnet sln Build.sln add "D:\a\_work\1\s\src\Microsoft.VisualStudio.ProjectSystem.Managed.VS\Microsoft.VisualStudio.ProjectSystem.Managed.VS.csproj" --solution-folder="D:\a\_work\1\s\artifacts\" 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') 1>D:\a\_work\1\s\eng\Build.proj(57,5): error MSB3073: The command "dotnet sln Build.sln add "D:\a\_work\1\s\src\Microsoft.VisualStudio.ProjectSystem.Managed.VS\Microsoft.VisualStudio.ProjectSystem.Managed.VS.csproj" --solution-folder="D:\a\_work\1\s\artifacts\"" exited with code 1. 1>Done Building Project "D:\a\_work\1\s\eng\Build.proj" (default targets) -- FAILED.Unlike @filipvh above, the paths here are absolute Windows paths that include a drive identifier. Perhaps that is being used as whatever is trying to create a "name" containing one of the invalid characters: / ? : \ * " < > |
I think the issue here is the attempt to create solution folder "D:\a_work\1\s\artifacts", which calls the code to create solution folder "D:", which is an invalid solution folder name as it contains ":"
For me there is also bug or change in behaviour when passing list of projects - before change in SDK proper solution was created (projects was in same subfolders like in folders on disk) but now it looks like all projects are inserted to the first subfolder that is created (I'm not exactly sure what is the logic). My workaround is to group my list of projects per subdirectory and add them separately but I don't know why this behaviour was changed
Do you have a repro example? Solution folders are automatically generated from the individual project's path: https://github.com/dotnet/sdk/blob/2e4b558e8a8655c464064a6405952fe36835e25f/src/Cli/dotnet/Commands/Solution/Add/SolutionAddCommand.cs#L72