Support Unfolding of VSTemplates

[jezzsantos]

Unfolding VS project templates is far less work than multi-file code generation.

[jezzsantos]

To create a template of this kind, you either do it through Visual Studio IDE, or manually create it on disk. Perhaps there are some shortcuts we can help do that with? Perhaps a command like automate edit create-vstemplate "/backendproject/backendproject.csproj" creates a template out of specified project file, and puts it somewhere for editing, or adds it the pattern in one step.

To install a *.vstemplate file into a patten we would have to upload the template into a VsTemplateCommand, where the (compressed file of some kind) is stored similarly to a codetemplate is. It can be editable there.

Not sure what being able to test it does? (needs investigation)

When we build the toolkit we encode it into the toolkit, like we do codetemplates.

When we execute it, we need to:

• first install it locally. Copy the stored files to a local directory (Desktop?)
• then, behind the scenes, install it (dotnet new --install <localcache>) see: https://docs.microsoft.com/en-us/dotnet/core/tools/custom-templates#get-a-list-of-installed-template-packages
• then unfold it dotnet new <templateid>
• then uninstall it dotnet new -uninstall <templateid>

This does mean that we are dependent on running dotnet CLI, which may not be installed in the local machine.

[jezzsantos]

We would have to have a strategy for dealing with the case when dotnet is not installed locally. We might have to check for its existence before being able to use it a authoring time, and using it at runtime.

running the VsTemplateCommand, at runtime, without dotnet being installed should always fail with a clear error message explaining how to fix it.

[jezzsantos]

A key design goal for automate is to be cross-platform and to not depend on any specific OS, nor any specific programming language, nor any specific IDE toolset.

We/community can always build specific extensions to specific IDE's (Vs, Rider, etc) using plugins for those toolsets, but the core capabilities cannot depend on them.

This means that supporting VSTemplates is a runtime feature that cannot be native to automate.

However, there are ways to accommodate unfolding VSTemplates that move the dependency to the specific toolkit rather than to the runtime.

Since VSTemplates are effectively a set of source files (.csproj or .cs files) that are bundled, compressed and installed into local template store by dotnet.exe then, all we would have to do to support them, is:

1. Add a command to upload (into a pattern) an arbitrary file. In the case of VSTemplates that is a *.vstemplate which is really a binary *.zip file. e.g. automate edit upload-file "c:\myfile.zip" --name MyFile1
2. Support a command (call it a CopyFileCommand) that can copy an uploaded file to a specific location on the local disk. this can support expressions for names etc. (just like a CodeTemplateCommand does). eg. automate edit add-copyfile-command "MyFile1" --withpath "~/location/{filename}.vstemplate"
3. We already support the ability to execute any command line executable (CliCommand). In the case of unfolding VSTemplates that would be a CliCommand using dotnet.exe, and pointing to a local location of the VsTemplate. e.g. automate edit add-cli-command "dotnet" --arguments "new --install {~/location/{filename}.vstemplate}"
4. Support a command to remove the arbitrary file from disk. e.g. automate edit add-deletefile-command "MyFile1
5. Again, using our CliCommand we issue an instruction to unfold the installed VsTemplate. e.g. automate new shortname.
6. Optionally, we can uninstall the VsTemplate after use. automate edit add-cli-command "dotnet" --arguments "new --uninstall {~/location/{filename}.vstemplate}"

We could also explore adding a custom validation rule that can be used to ensure a specific command line tool is installed on the machine (ie. that dotnet.exe is installed). Not sure yet how to configure that validation on a pattern/element. But the result is that a specific toolkit will fail any launchpoints if the custom validation rule fails. Perhaps consider a validation that specifies a specific platform for this specific toolkit. i.e. Windowsx64 that can be configured on the toolkit as well?

Problems:

• For just one VsTemplate, we are required to upload the file from local disk into the toolkit, then configure at least 4 separate runtime commands to manage installing it and using it in this toolkit. 5 runtime commands if you want to uninstalling it after use.