"dotnet sln add" emits error (yet succeeds) when adding project to an slnx (.NET 10 regression)

[AArnott]

Describe the bug

dotnet sln add emits an error message (yet succeeds) when adding a project to an slnx.

The error it emits references a project path that does not exist and is not referenced on the slnx. But it used to. The script that fails had recently removed the named project from the slnx. So how is it that dotnet sln "remembers" a prior version of the solution file in order to stumble over trying to access a project that used to be referenced by the file?

To Reproduce

git clone https://github.com/AArnott/Library.Template.git
cd Library.Template
git checkout issue/dotnet/sdk/51666
.\Expand-Template.ps1 -LibraryName Calc -Author Andrew

This error is produced (amidst other output):

dotnet : Invalid project `Q:\src\Library.Template\src\Library\Library.csproj`. The project file could not be loaded. Could not find a part of the path 'Q:\src\Library.Template\src\Library\Library.csproj'.  
Q:\src\Library.Template\src\Library\Library.csproj.
At Q:\src\Library.Template\Expand-Template.ps1:120 char:5
+     dotnet sln add "test/$LibraryName.Tests"
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (Invalid project...Library.csproj.:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

The line that failed is this one:

dotnet sln add "test/$LibraryName.Tests"

Interestingly, this command did succeed to add the new project to the solution. But it wrote an error as if it failed.

Further technical details

details of dotnet --info

.NET SDK: Version: 10.0.100 Commit: b0f34d51fc Workload version: 10.0.100-manifests.355811b7 MSBuild version: 18.0.2+b0f34d51f

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

.NET workloads installed:
[wasm-tools-net6]
Installation Source: VS 18.3.11207.16
Manifest Version: 10.0.100/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.workload.mono.toolchain.net6\10.0.100\WorkloadManifest.json
Install Type: Msi

[wasm-tools-net7]
Installation Source: VS 18.3.11207.16
Manifest Version: 10.0.100/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.workload.mono.toolchain.net7\10.0.100\WorkloadManifest.json
Install Type: Msi

[wasm-tools-net8]
Installation Source: VS 18.3.11207.16
Manifest Version: 10.0.100/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.workload.mono.toolchain.net8\10.0.100\WorkloadManifest.json
Install Type: Msi

[wasm-tools-net9]
Installation Source: VS 18.3.11207.16
Manifest Version: 10.0.100/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.workload.mono.toolchain.net9\10.0.100\WorkloadManifest.json
Install Type: Msi

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

Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
Version: 10.0.0
Architecture: x64
Commit: b0f34d51fc

.NET SDKs installed:
9.0.305 [C:\Program Files\dotnet\sdk]
9.0.306 [C:\Program Files\dotnet\sdk]
10.0.100-rc.2.25502.107 [C:\Program Files\dotnet\sdk]
10.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.21 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.21 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.0-rc.2.25502.107 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]

Environment variables:
DOTNET_CLI_DISABLE_PUBLISH_AND_PACK_RELEASE [1]

global.json file:
Q:\src\Library.Template\global.json

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

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

[AArnott]

It looks like it isn't that dotnet sln 'remembers' old versions. Rather, when adding test/$LibraryName.Tests, dotnet sln now parse the project file and finds a project reference that cannot be resolved. This would be resolved in a subsequent command in the script, and .NET 9 and earlier SDKs allowed this. .NET 10 reports this to STDERR as a new thing.

So I can workaround this by rearranging my script to fix the project reference before adding the test project back to the slnx.