R4Mvc.Tools migrating to a dotnet cli tool!

[artiomchi]

This has been a long time coming, but I've finally made progress with it.

The main issue was that the cli tools had to be written in .net core. In the tools project, we're using MSBuild, which still isn't accessible from .NET Standard (there are some discussions about it, but no progress as of now).

Recently Microsoft released .NET Core 2.1, which brought support for global tools. This means you can install a cli tool globally on your machine, and access it from any path, any project. You can also install it into a specific path, and access it from there.

What I did today is create a .NET Core wrapper cli tool that calls it's internal bundled copy of R4Mvc.Tools. It will only work on Windows (since the bundled project is compiled against .NET Framework), but it's much better than the current approach, and also removes the dependency on Visual Studio.

It might make sense to deprecate the current tools project in favour of the CLI only approach, but I wouldn't make that decision lightly. Even thought the project is still in alpha, there are some people using it, and this wouldn't be an obvious upgrade to anyone. As such, I've released it to MyGet under a new package ID (R4Mvc.Tools.Cli), and am asking for feedback and ideas on how we should proceed.

Current status:

The current approach to our R4Mvc.Tools project involves adding a reference to it in each project where you want it to be used. Visual Studio will call init.ps1 every time the project loads, and will make the Generate-R4Mvc command available. It can be called within the constraints of the project.
To call it from outside VS requires finding where it ended up being installed in your profile directory.

The new approach means you install the tool once, either as a global tool on your machine, or as a local tool in a predefined path (can even be added to your repo, and call it on the build server). Can be called from any command line very simply: r4mvc generate. Seems like a much better way all around.
The web project won't have any reference to it, so the upgrade path from the old approach to the new one isn't straightforward.

Then again, we're still in alpha

Going forward

I'm thinking of two main ways to proceed:

1. Deprecate the current Powershell aproach, and use the R4Mvc.Tools NuGet package ID for the new cli tool. Put up a notice on the NuGet package description and the GitHub repo regarding the changes, and include upgrade instructions. Will cause some confusion when users try to upgrade for the first time
2. Leave the current Powershell approach, keep maintaining it in parallel, and publish the new cli tool under the R4Mvc.Tools.Cli package name. Less confusion, but people won't know that the new package is available, and generally better

Side effects

While the new tool is generally better, easier to use, and removes the Visual Studio requirement, it does mean that you no longer have a specific version of R4Mvc.Tools tied to your project. You could have two different developers working ont he same project with different versions of the cli tool installed on their machines. When they run the tool, it might make different changes on each machine, causing issues, and downgrading features.

To prevent this from happening, I decided to add the build number into the r4mvc.json file, which is regenerated on every tool run. This way, if you run the tool with an older version than was used previously, you would either see it before committing your changes, or we could even display a warning and a confirmation prompt asking if they want to proceed and downgrade the generated code.

What does everyone think? @kevinkuszyk?

P.S. To test the current (first) build, you can run this command on a machine with .NET Core 2.1 installed:

dotnet tool install -g --add-source https://www.myget.org/F/r4mvc/api/v3/index.json r4mvc.tools.cli --version 1.0.0-ci--cli-tool-00274

Then navigate to a web project path, and just run:

r4mvc generate

[artiomchi]

As there were no feedback on this for over a month and a half, I'll proceed with adding it as a separate Cli package. This way we have both backwards compatibility, and users have the option to pick their approach.

If at some point we decide that the Powershell approach is wrong, we can always stop updating the package and delist it.

[artiomchi]

The CLI tool is now live, and can be installed from NuGet:

dotnet tool install -g r4mvc.tools.cli --version 1.0.0-alpha2-00307

I've also updated the docs with details about it's usage