Project tooling (PowerShell, dotnet-cli, other options?)

[artiomchi]

When you add a tool package to a project, VS adds it's path to the current PATH env variable to be able to run it's exe/cli/powershell commands. That works fine until you update that package. At that point the second package's path is added to the PATH variable, but since it's added at the end, and the previous path is still there, the first one takes precedence.

The end result is - after you update the tool and try to run it, it will run the old version of the code - until you restart Visual Studio (at which point it will re-populate the new PATH additions with only currently added packages).

The solution to this is to have a wrapper app that loads our tool as a library dynamically. This approach is implemented by the EFCore team, for example.

In the meantime, we have a "known issues" entry, saying if you update the package, you should restart your VS.

For alpha 1 I'm planning to add a simple workaround in the form of a uninstall.ps1 script that will remove the old version from the env PATH

[artiomchi]

I'm finally back from being away for so long, and started working on this (as the main outstanding issue for alpha 1).

I'm digging deeper into the .net code to see how they handled this on their side. Seems like the install.ps1 and uninstall.ps1 are no longer in use, and may be deprecated in the future, so I'm looking at alternative solutions.

The way EF Core are handling it is quite interesting/different. The user's end project will reference the Microsoft.EntityFrameworkCore.Design package, which contains the actual code for migrations, db sync, etc. The Microsoft.EntityFrameworkCore.Tools and Microsoft.EntityFrameworkCore.Tools.Dotnet packages are just a "bootstrap" package, that uses the Design library from the end project to run the code.

We can't use the same approach, since we can't just reference the build tools and code analysers in the user's web project - that would be silly and would cause issues.

I'm checking a couple other tools libraries to see how they handle this issue

[artiomchi]

Digging deeper, I finally made some progress.. I've switched the name of the issue to change it into a discussion on tooling in general, rather than making it PS specific

First things first, I've managed to make the PowerShell tooling work in a reliable way. (i.e. it will pick up the latest version of the tools after each update without the need for a VS restart!) As such, I think we can go ahead with a first alpha (my MyGet fields are still being updated too).

Here's what I had so far in terms of a plan for the tools. We'll have two options that users can use. Both will provide the same level of functionality, the only difference is how they're invoked. While I'll strive to make them cross platform if possible, that doesn't seem to be an option at the moment, since MSBuild is only compiled against the full .NET framework. Once that changes, we should be able to make R4Mvc generation cross platform as well.

1. PowerShell commands invoked in the Package Manager Console inside VS
   • Get-R4MVCStatus analyse the project, checking whether the project has any R4Mvc generated code
   • Generate-R4MVC main command that will invoke the R4Mvc generators
   • Remove-R4MVC will attempt to remove all custom code from the project (sans removing partial and virtual keywords)
2. dotnet cli, which can be invoked either inside VS or from a command line in the project's path
   • dotnet r4mvc default command showing whether the project has any R4Mvc generated code, as well as a short help message with usage examples
   • dotnet r4mvc generate main command that invokes the R4Mvc generators
   • dotnet r4mvc remove - will attempt to remove the custom code from the project

Currently we only have the generate command, and I'll only start on the others when the core functionality is finished, so the others are really a backlog issue.

dotnet cli support is also in progress, although it's not quite there yet. Seems like the project that contains the cli commands HAS to be multi platform, otherwise we won't be able to add it to most projects. That explains why EF has separate projects for the PowerShell and the dotnet cli tools.

[kevinkuszyk]

@artiomchi looks like a good approach to me. Shall we open issues to track progress on each of the commands and then close this one?

[artiomchi]

Yup, that makes sense. I'll go over them and create 4 new issues to replace this one with a proper write-up this evening