pauldeen79 / texttemplatetransformationframework Goto Github PK

Run, sourcecode, extract templates and code generation assembly commands should support watch argument
-w|--watch

• Console.ReadLine() until "exit"
• Add filesystemwatcher, re-execute on every change
• Also execute first time (as we're doing now)

Rename t4plus to template

After this, you can do this:

template run mytemplate.template

On the other hand... Is this really necessary?

The assembly command needs to be improved in two ways:

• When you give a relative path to an assembly, first convert it to a fully qualified path. If we don't do this, Assembly.LoadFrom will throw an exception.
• When you don't give a custom path for assembly resolving, and the assembly name is a filename (ends with .dll), then use the path of this dll as custom path

Using these two improvements, you can now simpy use t4plus assembly -a myproject\bin\debug\net7.0\myproject.dll
Instead of t4plus assembly -a c:\fullpath\myproject\bin\debug\net7.0\myproject.dll -p c:\fullpath\myproject\bin\debug\net7.0

Use C# raw string literals instead of T4 for templating.

If this works, we can remove all T4 stuff and the template parsing (token) stuff.
What will remain, is just the Runtime project (without template specific stuff) and the Cmd project (without template specific stuff)

Advantages:

• Easy debugging from your IDE of choice
• Intellisense from your IDE of choice
• No additional steps for references - .net core will take care of this
• We can throw away a lot of code

The proof of concept needs to include this:

• One template without reference to the Runtime project
• One template with reference to the Runtime project
• Try both with and without Model property on the root template - note that for testing, you will need the Runtime project
• Include child templates, and add code if needed to support this
• See if we can refactor those ugly Func delegates - especially if we need them. Just use standard DI with constructor injection.

See for more info:
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/raw-string
https://devblogs.microsoft.com/dotnet/csharp-11-preview-updates/

• Store templates using short name
• install and uninstall command to install and uninstall a template
• list-templates command to list installed templates
• First version: Only a single contained template file or assembly with the (single) template class. When you have multiple files, generate the source code and then use the assembly.
• First version: Do not copy the template to a central location. You just have to make sure the file remains available.
• Store template configuration in a central location, i.e. %userprofile%/.t4plus/templates.config
• The t4plus run --short-name command tries to resolve the short name. If it fails, it shows an error message.

  Using this, you can call t4plus run --short-name from any directory on your computer for code generation.

Currently, we support the following types:

• Single template, parsed from text and then compiled into a single class in an assembly which can be executed
• Code generation assembly, with multiple code generation providers that are all run and put into a MultipleContentBuilder

We want to add this type:

• Single template, referred to using an assembly name and class name

This type can be a simple template, or internally use a MultipleContentBuilder and return that. The differences are:

• The template is already compiled into an assembly, and doesn't need to be parsed (which gives you far better performance)
• You can include multiple resources, assembly references and so on. These don't have to be resolved at run-time

We have to think of a command to run this template. Or maybe just think of a name for this kind of template.

What about t4plus run -a project\bin\debug\my.dll -t MyNamespace.MyClass Arg1:Value1 Arg2:Value2
-a | --assembly
-t | --type
-u | --use directory (optional)

In the run command, either the filename or the assembly and typename are required.

Advantages:

• Single file, which is useful for example for global templates. Just store the dll (and possible nuget package reference dlls) in one directory, no need for a tree structure with includes or child templates
• Better performance, no need to parse and compile
• Can also be packed into a nuget package (maybe we can add support for this later... t4plus install https://nuget.org/mytemplate --version 1.0.0

You can use these assembly templates for both running and extracting parameters.

Maybe it would be a good idea to generate a .csproj file on the fly, calling dotnet build to generate an assembly and all nuget references in a temporary directory. This way, we don't have to store assemblies in the temp folder, and this also fixes resolving assemblies from nuget packages. (do we need "lib", or which target framework do we need?)

Edit: Maybe it would be a better option to use assembly templates. You can do whatever you want, just copy all the package binaries to the output directory and use that as probing path. (is already performed when you use the file name of the assembly)

• Silent/bare, which only writes the output and nothing else
• Clipboard, which copies the output to the clipboard

This makes it possible to use it from the command line. For example, you can pipe the bare output to the clipboard. Or even let the t4plus command-line tool copy it to the clipboard for you.

When using T4Plus, if you have a template that doesn't have the template directive, then you get an exception in the template factory. (after compiling the assembly, and trying to render the template)

Also, the Initialize method does not include any code. This is wrong.

In the token parser, a template directive should be inserted if it's not found. This will fix this issue.

Optional class name filter for code generation provider command.

Currently, all code generation providers are run. You should be able to provide (multiple) class names for filtering.

For example, t4plus assembly src\codegeneration\bin\debug\net7.0\codegeneration.dll

This runs all ICodeGenerationProvider instances from codegeneration.dll. If we need command-line options, add them to the command. (I can think of DryRun and Path)

The command will detect all code generation providers using reflection.