Describe the bug
Running dotnet sln remove on an path that isn't in the solution throws a NullReferenceExceptions instead of gracefully printing a message. This only happens when:
- A .slnx file is used instead of a .sln file
- The .slnx has at least one project in it. An empty slnx file will correctly print the message.
Steps to reproduce
mkdir test ; cd test
dotnet new sln -f slnx
dotnet new classlib
dotnet sln . add .
dotnet -d sln . remove invalid
Expected behavior
This should print out:
$ dotnet sln . remove invalid
Project `invalid` could not be found in the solution.
Above is from running in a mcr.microsoft.com/dotnet/sdk:10.0.100-preview.2 container
Actual behavior
It currently prints out:
$ dotnet sln . remove invalid
Object reference not set to an instance of an object.
$ dotnet -d sln . remove invalid
Telemetry is: Enabled
Microsoft.DotNet.Cli.Utils.GracefulException: Object reference not set to an instance of an object.
---> System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.DotNet.Tools.Sln.Remove.RemoveProjectFromSolutionCommand.<>c__DisplayClass4_0.<RemoveProjectsAsync>b__0(SolutionProjectModel p)
at System.Linq.Enumerable.ArrayWhereIterator`1.GetCount(Boolean onlyIfCheap, ReadOnlySpan`1 source, Func`2 predicate)
at Microsoft.DotNet.Tools.Sln.Remove.RemoveProjectFromSolutionCommand.RemoveProjectsAsync(String solutionFileFullPath, IEnumerable`1 projectPaths, CancellationToken cancellationToken)
at Microsoft.DotNet.Tools.Sln.Remove.RemoveProjectFromSolutionCommand.Execute()
--- End of inner exception stack trace ---
at Microsoft.DotNet.Tools.Sln.Remove.RemoveProjectFromSolutionCommand.Execute()
at System.CommandLine.Invocation.InvocationPipeline.Invoke(ParseResult parseResult)
at System.CommandLine.ParseResult.Invoke()
at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, TimeSpan startupTime, ITelemetry telemetryClient)
The above is from a mcr.microsoft.com/dotnet/sdk:10.0.100-preview.3 container.
Is this a regression?
I tracked the breakage down to SDK 10.0.100-preview.3. SDK 10.0-100-preview.2 is ok. SDK 9.0.315 (latest at time of writing) is also unaffected.
Are there any workarounds?
You'll have to check the paths manually before calling dotnet sln remove. Since when it throws, it stops processing the rest of the arguments.
dotnet --info output
.NET SDK:
Version: 10.0.301
Commit: 96856fd726
Workload version: 10.0.300-manifests.8c7d7c03
MSBuild version: 18.6.4+96856fd72
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.301\
.NET workloads installed:
There are no installed workloads to display.
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.9
Architecture: x64
Commit: 901ca94124
.NET SDKs installed:
6.0.428 [C:\Program Files\dotnet\sdk]
7.0.410 [C:\Program Files\dotnet\sdk]
8.0.422 [C:\Program Files\dotnet\sdk]
9.0.100-rc.2.24474.11 [C:\Program Files\dotnet\sdk]
9.0.315 [C:\Program Files\dotnet\sdk]
10.0.109 [C:\Program Files\dotnet\sdk]
10.0.301 [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 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.28 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.0-rc.2.24474.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 5.0.17 [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.28 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.0-rc.2.24473.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 5.0.17 [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.28 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.0-rc.2.24474.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.9 [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
IDE version
No response
Other details
No response
Describe the bug
Running
dotnet sln removeon an path that isn't in the solution throws a NullReferenceExceptions instead of gracefully printing a message. This only happens when:Steps to reproduce
Expected behavior
This should print out:
Above is from running in a
mcr.microsoft.com/dotnet/sdk:10.0.100-preview.2containerActual behavior
It currently prints out:
The above is from a
mcr.microsoft.com/dotnet/sdk:10.0.100-preview.3container.Is this a regression?
I tracked the breakage down to SDK 10.0.100-preview.3. SDK 10.0-100-preview.2 is ok. SDK 9.0.315 (latest at time of writing) is also unaffected.
Are there any workarounds?
You'll have to check the paths manually before calling
dotnet sln remove. Since when it throws, it stops processing the rest of the arguments.dotnet --info output
IDE version
No response
Other details
No response