Proposal: Build dotnet tool to emulate dotnet.exe (one executable with all of the commands)

[NightOwl888]

ikvmc.exe was named so to model it after csc.exe, and other IKVM tools (ikvm.exe and ikvmstub.exe) are to handle other tasks, similar to the way .NET Framework used al.exe and sn.exe to handle other task. However, the new generation of .NET build tools uses a common executable (dotnet) which contains multiple commands, each with their own parameters, options, and help.

@wasabii have been discussing this a bit, and he correctly pointed out that the tools like csc.exe and al.exe still exist, but at a lower level, and each have a singular purpose. So this proposal isn't necessarily to eliminate the existing tools, but to roll the functionality into a dotnet tool that can be installed on the command line using dotnet tool install which will combine their functionality.

Having a dotnet tool on NuGet is far fewer steps to deal with than downloading and extracting .zip files before running commands in build scripts and you don't need to specify a URL, just an id and a version of the package. The installer handles which binaries get installed depending on OS and platform, so although we may have separate builds for each OS they can be accessed by all users in a single way.

One option to simplify building such a tool is the CommandLineUtils package, although for lucene-cli we ended up copying the (original) source, patching bugs, and adding support for localized resources, where the original code patched other bugs, added DI support, but is no longer accepting new features and still doesn't support localization.

Ideally, we would follow common conventions:

• Tool name: ikvm-cli
• Main command: ikvm, which other commands are nested below

Commands would be converted to match .NET

• ikvmc -> ikvm build
• ikvm -> ikvm run
• ikvmstub -> ikvm stub

We could use ikvm with the original parameters and simply pass them to ikvm run to avoid confusion in case anyone is following the old documentation.

And of course we can nest other commands and options below these, as needed.

• Parameters would be required in a specific order and are not specified with an identifier. They may be required or optional.
• Options would be changed to use -v (short) and --verbose (long) values followed by a space rather than a colon : for options that accept a value.
• Validation will be performed on parameters to ensure that required parameters are provided and conflicting options are not allowed.

[wasabii]

I did already leave a place for this in the IKVM.Tool project. I thought I might give it a go. But then ran into the mess that was ikvmc, stub, etc, and how they stumble into forked copies of IKVM.Runtime, etc.

I think at least some of that should be cleaned up first. Mainly the core logic of these tools needs to be moved a bit more cleanly out of the tools themselves, into libraries that can be shared by both the Runtime itself and the tools. They all use parts of the Runtime, but with different IFDEF patterns.

This would be a prerequisite for making the tooling better accessible from MSBuild as well. We'd want custom tasks for the same functionality.

[wasabii]

Ikvmreference obsoletes this