Breaking Change in System.CommandLine (2.0.0-beta4.25072.1): Cli Prefix Renamed

[tautcony]

Description

The latest release of System.CommandLine(2.0.0-beta4.25072.1) introduced a breaking change by modifying the Cli prefix. For example, CliRootCommand has been renamed to RootCommand. This change affects the functionality of the library.

Commit reference:

See related commit: 060374e

[calacayir]

They just cannot decide with the naming convention, lol. I am now working on updating to latest daily build 2.0.0-beta4.25072.1 of System.CommandLine and fixing the naming issues. I will let you know shortly.

[moh-hassan]

It is announced: adjust to System.CommandLine renaming and here 5 days ago that System.CommandLine team are working on releasing a new public version of System.CommandLine.
The only change they decided to revert was the adding of "Cli" prefix to all symbol types (because it would break every single user of the library).
The PR is done by removing the Cli prefix for example, sample of pr

@calacayir

am` now working on updating to latest daily build 2.0.0-beta4.25072.1 of System.CommandLine and fixing the naming issues

Just, i suggest to avoid re-modification, to wait for the change until the release of the public version :)

[calacayir]

Ok, it's already completed now with 8e28d56 , I guess they will keep these names from now on. If there is a new public release after 2 years, then we can reference that package version rather than bundling latest beta in our package.

DotMake.CommandLine v1.9.0

[adamsitnik]

Hello everyone!

My name is Adam, I am one of the engineers from the .NET Team who is currently working on System.CommandLine.

First of all, I wanted to say that I am impressed by what you were able to build on top of System.CommandLine.

I can't say much in public about our plans (because I am just an engineer and it could be perceived as a promise made by Microsoft), but I wanted to ask you for feedback about the current API shape. Namely: is there anything that you believe has to be addressed before shipping a new version of System.CommandLine to NuGet.org?

Thanks,
Adam

[calacayir]

Hi Adam,
Thanks for your comments and work on your library, we are just trying to offer syntactic sugar on top of System.Commandline. We have been using latest beta versions from your private nuget feed for months and we didn't experience any problems so it looks pretty stable. For future versions, we can recommend:

• Making help output related classes more customizable, for example we need to copy symbol formatting methods to our library because they are internal in your library. We override your HelpBuilder class to use themes/colors and it works fine. Maybe in future you can separate populating and presentation of symbols.
  https://github.com/dotmake-build/command-line/blob/main/src/DotMake.CommandLine/CliHelpBuilder.cs

• We have a small fix on parsing of System.Commandline:
  On Windows platform, backslash + double quote (\") at the end of an argument,
  is usually a path separator and not an escape for double quote, so it will be trimmed to prevent unnecessary path errors.
  Related to ClicCommand.Parse escapes backslash when parsing arguments dotnet/command-line-api#2334, Pass JSON as argument dotnet/command-line-api#2276, Parse Environment.CommandLine directly vs trusting string[] main dotnet/command-line-api#354
  We use this code to fix it:
  

  command-line/src/DotMake.CommandLine/Cli.cs

  Lines 342 to 370 in 4ead00a

  	private static string[] FixArgs(string[] args)
  	{
  	if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows)
  	&& args != null)
  	{
  	/*
  	On Windows, trim ending double quote:
  	For example, if a path parameter is passed like this:
  	--source "C:\myfiles\"
  	The value comes as
  	C:\myfiles"
  	due to CommandLineToArgvW reading backslash as an escape for double quote character.
  	As on Windows, backslash at the end is usually a path separator, trim it to prevent unnecessary errors.
  	Note that this is not required for commandLine string as in that case SplitCommandLine is used,
  	and it already trims double quote characters
  	https://devblogs.microsoft.com/oldnewthing/20100917-00/?p=12833
  	https://github.com/dotnet/command-line-api/issues/2334
  	https://github.com/dotnet/command-line-api/issues/2276
  	https://github.com/dotnet/command-line-api/issues/354
  	*/
  	for (var index = 0; index < args.Length; index++)
  	{
  	args[index] = args[index].TrimEnd('"');
  	}
  	}
  	return args;
  	}