It's a nice idea, and anything that gives .NET developers more power at the command line is going to get a thumbs up from me. But "one command to rule them all" does feels a little broad. To take a ruby/rails/linux equivalent, this is apt-get, ruby, irb, rails and gem all rolled up together.
Perhaps I'm just overly familiar with the unix small tools philosophy.
the dotnet is like git, so `dotnet compiler` just call `dotnet-compiler`
the first level tools ( dotnet-compile, dotnet-restore ) read the project json ( the only supported project file atm ) and pass argument to second level tools.
for example:
- dotnet compiler call dotnet-compile
- dotnet-compile read source files, references, defines from project.json and call dotnet-compile-csc with the source files as arguments.
- dotnet-compile-csc call csc
- if --native, another .net bytecode to native tools is called
and csc (csharp compiler) is bundled with the dotnet cli package.
> To take a ruby/rails/linux equivalent, this is apt-get, ruby, irb, rails and gem all rolled up together
Once you have fetched ruby I'd be much happier if it was all one command "ruby" for fetching packages, building, running etc. That doesn't mean it can't be several pieces of code running in the end, but from the end user perspective one top level util for one set of tasks makes sense.
Compare "git lfs foo baz" with "git-lfs foo baz". I think the first is a lot better, even if what happens is closer to the second.
Perhaps I'm just overly familiar with the unix small tools philosophy.