-
Notifications
You must be signed in to change notification settings - Fork 413
Description
Description
While using System.CommandLine 2.0.1 on .NET 10, I noticed that the package exposes an API surface that does not match the documentation or the expected stable 2.0.1 API.
Even though the runtime assembly reports version 2.0.1.0, the compiler sees API signatures that match 2.0.0‑beta4, for example:
Option<T>.Requiredexists, butIsRequireddoes notRootCommand.Options.Add(...)exists, butAddOption(...)does notRootCommanddoes not containInvokeAsyncSetHandlerexists, but other 2.0.1 APIs are missing
This results in a hybrid API surface:
runtime = 2.0.1, reference assemblies = beta API.
Expected behavior
The 2.0.1 NuGet package should ship reference assemblies that match the documented 2.0.1 API, including:
IsRequiredAddOptionInvokeAsynconRootCommand- Updated command/handler patterns
Actual behavior
The compiler exposes the older beta API surface, while the runtime loads the 2.0.1 assembly. This causes documented samples to fail to compile and forces developers to fall back to beta-era APIs.
Reproduction steps
-
Create a new .NET 10 console project
-
Add:
<PackageReference Include="System.CommandLine" Version="2.0.1" />
-
Attempt to use documented APIs such as
IsRequiredorAddOption. -
Observe that the compiler reports these members do not exist.
-
Print the runtime assembly version:
csharp Console.WriteLine(typeof(System.CommandLine.Command).Assembly.GetName().Version);Output:
2.0.1.0
Environment
- .NET 10
- System.CommandLine 2.0.1
- Windows 11
- Reproducible in a clean project with no other dependencies
Impact
This mismatch makes it difficult to rely on the stable release, since:
- Documentation does not match the shipped API
- Code samples fail to compile
- Developers must fall back to beta-era APIs
- The package appears stable but behaves like a preview
Request
Please update the 2.0.1 package (or release a 2.0.2) with correct reference assemblies that match the intended stable API surface.