CLI Roadmap

[richlander]

The dotnet CLI is a driver for a set of distinct and standalone commands. We need to prioritize these commands so that people can use them E2E for common tasks (like conference demos). These are broken into priorities.

Commands

This document just lists the command and doesn't explain what they do. It links to other issues that go into depth on those commands, as available. Some of these commands may not be the final syntax. We'll fix that.

Demo (--native)

• dotnet dotnet --help command #4301
• dotnet init dotnet/cli#192
• dotnet help dotnet --help command #4301
• dotnet compile dotnet/cli#48

Converge with DNX

• dotnet publish
• dotnet publish-web
• dotnet restore dotnet/cli#79
• dotnet run dotnet/cli#59
• dotnet test
• dotnet pack

Additional Features

• dotnet install-package dotnet/cli#76
• dotnet clean dotnet-clean command #4294
• dotnet api dotnet/cli#106
• dotnet format
• dotnet repl

Open Issues for toolchain convergence:

• Resource/Satellite Assemblies (resgen + compile)
• Global commands
• NuGet integration (remove DNU Restore)
• Build Events in Project.json
• Performance
• OSSSigning
• Acquisition of toolchain
• VB/F# Support

Hosting convergence:

• Finding and installing shared runtimes (DNVM, shared hosting, servicing)
• Assembly
• Azure performance

Corefx usage of cli:

• Using dotnet cli in corefx
• Custom .NET directory structures
• Integration with MSBuild

VSIntegration:

• csproj and xproj
• debugging
• launching
• Many more
• VB/F# Support

Languages

P0

• C#

P1

• F#
• VB

[TheRealPiotrP]

AFAIK, compile --il is a pre-req for compile --native. Why do we need a separate compile --il, then?
compile, in one version of the story, did the end to end [restore, compile il, compile native]. Is that still the intent? Or do we now want the demo to issue several commands?

It would be nice to have issues per-command where these sorts of details are worked out...

[richlander]

@piotrpMSFT You need to be able to compile IL EXEs and DLLs, too. This isn't a "native compilation toolchain". It needs to support ASP.NET 5 use cases.

I've now added a writeup for compile. That should help a lot. See dotnet/cli#48.

[weshaggard]

What is the intended configuration file for these commands? Is the project.json file intended to provide the necessary configuration information for all these commands? If project.json is the new project file how do we reconcile that with the msbuild project file? I've seen xproj's but I'm not sure how they connect exactly. At any rate it would be good to also include information on this in some spec as well.

[justinmchase]

When you add support for VB/F# it would be really nice if you added support for 3rd party languages as well. I would consider coming back to the .net community if there was a reasonable api for plugging new languages into this new system.

For example:

"language": "boo"

In the project file it would assume that my project is boo and would use the 3rd party compiler instead.

[dburriss]

Are custom commands going to be supported? I know there was something similar in dnx but I was almost sure there was documentation for doing this for the CLI but it seems I was wrong.

[blackdwarf]

@dburriss custom commands are supported on per-project basis. Global commands like what DNU provided with DNU commands are not going to be supported at least for V1.

[dburriss]

That is good to know. Are there any resources on getting started with custom commands? If we eventually got global commands would they be able to fill a space like gems in ruby or packages in node?
Eg.
RUBY

gem install jekyll
jekyll new SomeNewSite

DOTNET (hopeful)

dotnet install njekyll
dotnet njekyll new SomeNewSite

Note: njekyll doesn't exist as far as I know. Just an example.

[blackdwarf]

This document is now hopelessly outdated. I'm just going to close this issue.

[tugberkugurlu]

where is the up-to-date roadmap?