Move MultiValueDictionary, CommandLine, and Drawing.Graphics projects to archives.

[ahsonkhan]

Part of corefxlab repo cleanup.

Removing these projects from the corefxlab solution and into the archives directory.

• System.Collections.Generic.MultiValueDictionary
• System.CommandLine
• System.Drawing.Graphics

cc @dotnet/corefxlab-contrib, @davidfowl, @pakrym, @JeremyKuhne, @atsushikan, @adamsitnik, @benaadams, @ericstj, @eerhardt, @terrajobst, @KathleenDollard, @tannergooding, @livarcocc, @crummel

[ahsonkhan]

Including other contributors (FYI):
cc @krwq, @sokket, @hughbe, @jamesqo, @bricelam, @daveaglick, @tarekgh

[daveaglick]

What does "archived" mean? Are those projects that never made it out of the incubation phase and aren't expected to graduate? Does it have any implications with regard to future MS investment or community contributions (will PRs get reviewed and merged, etc.)?

I have a couple comments/suggestions:

• Add something to the main readme indicating which projects can be found in the archives and remove those project from the "Components" section. Also add a little information about archived projects like the answers to my questions above.
• Consider maintaining the folder structure for tests vs. src instead of placing both types of projects directly under archived_projects.

[YohDeadfall]

Does this mean that CommandLine has no future and will never be published?

[adamsitnik]

Does this mean that CommandLine has no future and will never be published?

@KathleenDollard is the best person to answer this question

[bricelam]

Similar codebases of interest:

• Microsoft.DotNet.Cli.CommandLine
• Microsoft.Extensions.CommandLineUtils

[tarekgh]

I am seeing libgd.dll is deleted here and looking at the history I am seeing it got renamed before. This version of this dll is hard to find or build. any reason this got renamed and deleted? This is x86 version of this DLL.

[ahsonkhan]

What does "archived" mean? Are those projects that never made it out of the incubation phase and aren't expected to graduate? Does it have any implications with regard to future MS investment or community contributions (will PRs get reviewed and merged, etc.)?

Yes, they never made it out of the incubation phase and we will no longer publish new packages to MyGet for them. These projects either don't have any active contributions or stewards to carry them forward, or the design is not ideal. Given corefxlab is meant for experimentation and prototyping, these projects have served their purpose.

Add something to the main readme indicating which projects can be found in the archives and remove those project from the "Components" section. Also add a little information about archived projects like the answers to my questions above.

I will do that.

Consider maintaining the folder structure for tests vs. src instead of placing both types of projects directly under archived_projects.

Good idea. I will fix this.

This version of this dll is hard to find or build. any reason this got renamed and deleted?

I will add it back.

[tarekgh]

Drawing.Graphics looks good to me.

[ahsonkhan]

@dotnet-bot test Innerloop OSX10.12 Debug Build and Test

[terrajobst]

@YohDeadfall

Does this mean that CommandLine has no future and will never be published?

We're still interested in addressing the scenario but based on feedback from both internal & external adopters we don't believe this particular API has a future. Stay tuned.

[martinzima]

May I ask what was the reason for archiving MultiValueDictionary in particular? Was there anything conceptually wrong with it?

[YohDeadfall]

The question was already answered by @ahsonkhan. See #2245 (comment).

[Athari]

@terrajobst

We're still interested in addressing the scenario but based on feedback from both internal & external adopters we don't believe this particular API has a future. Stay tuned.

Could you provide more information about the feedback on the API of CommandLine? What exactly is problematic about it? I haven't used the library myself, but I actually like its API, it seems clean, powerful and extensible, unlike some other popular libraries (cough CommandLineParser cough) provide.

[MarcoRossignoli]

Could you provide more information about the feedback on the API of CommandLine? What exactly is problematic about it?

@Athari i agree with you...i need "command line parsing" two three times a year...and now with new .net tools maybe could be very useful a "standard" parsing lib.
What do you think @natemcmaster?I found also a similar util in your repo https://github.com/natemcmaster/CommandLineUtils

[eerhardt]

Note that there is also https://github.com/dotnet/CliCommandLineParser, which is what the .NET Core SDK's command line uses.

It has the advantage that it also supports auto-completion for shells that support it (powershell, bash, etc). That way a user can type dotnet bu, hit TAB, and the command line will be completed with dotnet build.

From my understanding, dotnet/CliCommandLineParser was built to support auto-completion and to support deeply nested command structures that were required by the .NET Core SDK.

@jonsequitur, @TheRealPiotrP, and @livarcocc would have more details if you need them.

[KathleenDollard]

Several of us who passionately agree with those of you thinking there should be a better parser story have been working on a side project of a new parser. I realize that another parser is a bit annoying, but a good parser turns out to need far more design than you might expect. This project ("System.CommandLine") has design leadership from several people that have extensive experience with parsers, including @jonsequitur. It also solves other problems with command line input ant output including cross-terminal auto-complete and output (xterm/vt100 support).

The current status is that we are very happy with the internal architecture - the foundation. We are very unhappy with the API. We will go public on NuGet and GitHub as soon as we iron that out, and plan to do that by the end of September. If you have a chunk of time (it's not in a state where contribution is easy, which is why we aren't public) and passion, let me or @jonsequitur know and we can hook you up as a contributor.

I also think this is a good model for other things archived like MultiValueDictionary. If a group of people understand the problem, and want to take the code and idea forward as an OSS project, that would be great. It's one of the values of having this play space (and an experimental space means by definition we'll consider some not worth moving forward) is that this work is in the open and can be picked up.

Kathleen

[MarcoRossignoli]

@KathleenDollard in these weeks i'm working on a "simple" command line app for .net core. If you want i could try to use your System.CommandLine in "production".

If a group of people understand the problem, and want to take the code and idea forward as an OSS project, that would be great. It's one of the values of having this play space (and an experimental space means by definition we'll consider some not worth moving forward) is that this work is in the open and can be picked up.

I'm not a "command line" expert but maybe i could help with development in somehow(testing or other).

[Athari]

@KathleenDollard Please comment in this thread when you go public.

[KathleenDollard]

@Athari I plan to shout from the rooftops :)

[JeremyKuhne]

@KathleenDollard I'm looking at improving string formatting performance for System.Console. If that overlaps at all please feel free to loop me in.

[jonsequitur]

There were some questions about this here earlier. If you're interested interested in what we've been working on, please take a look: https://github.com/dotnet/command-line-api.