Sdk: Remove usage of System.CommandLine

[Petermarcu]

CLI will be using a private copy of Microsoft.Extensions.CommandLineUtils.Sources.

https://github.com/dotnet/corefxlab/issues/655 .

Tracking here for the rc2 release. We need to see if this can support netstandard1.1 to run on 4.5.1.

@piotrpMSFT @Eilon

[TheRealPiotrP]

@Eilon @anurse We're using multiple command line parsers in CLI today. Do you have a desire to use System.CommandLine, or is the replacement of its usage in Compiler.Common a suitable alternative?

[Eilon]

@piotrpMSFT original bug is here: https://github.com/dotnet/cli/issues/1540

We need ProjectModel.Loader and ProjectModel.Workspaces for .NET 4.5.1, but they depend on other libraries (e.g. some variation of System.CommandLine) that use netstandard1.5, so it won't compile.

[anurse]

Also to be clear, netstandard1.2 is sufficient for .NET 4.5.1 (https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#mapping-the-net-platform-standard-to-platforms)

[TheRealPiotrP]

@mellinoe is looking into this. it looks like there are dependencies blocking this.

[TheRealPiotrP]

@Eilon any chance you guys could look into making a PR that breaks the CLI's dependency on System.CommandLine? We're not going to be able to get to this immediately.

[eerhardt]

FYI - I have started working on this.

The general approach is to remove System.CommandLine from CLI.

However, one of the biggest issues to tackle is that Microsoft.DotNet.Compiler.Common.dll is exposing methods that use types from System.CommandLine.

https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.DotNet.Compiler.Common/CommonCompilerOptionsExtensions.cs#L45
https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.DotNet.Compiler.Common/AssemblyInfoOptions.cs#L76

My current plan is to remove these methods from Microsoft.DotNet.Compiler.Common, and make them "shared source" between the src\dotnet and src\dotnet-compile-fsc projects. If anyone thinks this is going to be a problem, please let me know as soon as you can.

/cc @cdmihai @agocke @pakrym

[agocke]

@eerhardt That type/helper is meant to be a common utility that any dotnet compiler can implement to get the shared functionality specified by the CommonCompilerOptions. How do you propose other compilers use this code without living inside the CLI repo?

[anurse]

We can still publish the package as a shared-source package and other compilers can reference it.

[agocke]

Cool, LGTM then.

[eerhardt]

My thought is AssemblyInfoOptions and CommonCompilerOptions types will still live in that assembly. The only thing I'm pulling out is the Parse methods that rely on System.CommandLine.ArgumentSyntax.

The hope is that someday we will have an official "CommandLine" utility, but until that day comes, we can't ship our public APIs using this unofficial package.

[agocke]

@eerhardt Right, I would assume they _must_ live in that core assembly, since otherwise the types may not unify across assembly boundaries.

[eerhardt]

The PR to remove System.CommandLine from CLI is ready to review - dotnet/cli#2594.

Barring legal hurdles with copying the 5 DNX files into our repo, this should be merged today.

(The legal hurdles are that the copied DNX code has a copyright header that uses the Apache v2 license, whereas the rest of the CLI code has MIT license. I'm not sure exactly how to approach this. Anyone with insight please let me know.)

[Eilon]

@eerhardt I'll contact you over email.

[MichalStrehovsky]

Since e.g. Roslyn targets netstandard1.3 will targeting netstandard1.1 in the CLI buy anything?

(I'm asking because the CoreRT native compiler targets 1.3 as well).

[Petermarcu]

I think the main problem @Eilon is trying to solve is that they use some specific libraries that are built from the CLI repo. For those libraries in particular, they need their dependency graph to work on netstandard1.1.

[TheRealPiotrP]

This change also removes a point of complexity from CLI's dependency graph. It's a win overall.

[MichalStrehovsky]

It's a win overall.

Except it has a subtle message: "Hey, we have this cool System.CommandLine package for you. We don't eat our own dogfood because we make food for us on the side, but hey maybe it will work for you."

[Eilon]

System.CommandLine is part of corefxlabs, it's not a supported product.