Documentation | Getting Started | Supported Platforms | Need Help?
Pros: Easy to use, rapid to implement
Cons: Attributes are part of the build, annotation assemblies have to be published and loaded when reflection is used
Install nuget package KY.Generator
Decorate a class with one of our Generate attributes
using KY.Generator;
...
[Generate("Output")]
internal class TypeToRead
{
public string Property { get; set; }
}
See the complete showcase
See documentation for more details
Pros: generator code is completely separated and is not published, more actions are available than via annotations
Cons: the initial setup is not so easy as with annotations
Create a new class library project
Install nuget package KY.Generator.Fluent
Derive a class from GeneratorFluentMain, override the execute method and use the Read method
public class GeneratorMain : GeneratorFluentMain
{
public override void Execute()
{
this.Read()
.FromType<Types>()
.Write()
.AngularModels().OutputPath("Output/Models").NoHeader()
.AngularServices().OutputPath("Output/Services").NoHeader();
}
}
See the complete showcase
See documentation for more details
dotnet tool install -g KY.Generator.CLI
Run a command
ky-generator reflection -assembly=KY.Generator.Examples.Reflection.dll -name=ExampleType -namespace=KY.Generator.Examples.Reflection -relativePath=Output -language=TypeScript
The tool ships every built-in module, so nothing has to be installed next to it. It requires the .NET 8, 9 or 10 runtime; an assembly built for one of those is read by a matching process, whichever of them the tool itself was started on.
See documentation for more details
Options that are the same for every project of a repository can be set once in a ky-generator.json instead of
being repeated in the assembly attributes of each project.
The search starts in the directory above the project and walks up to the root of the drive - at project level the assembly attributes are the way to configure the generator. The settings of the machine, in the application data folder, are the outermost layer, so every file found in the tree wins over them, and every file wins over the one above it. On top of that come the assembly attributes, the fluent syntax and the CLI parameters, in that order.
ky-generator settings-init # write a file with every option and its default
ky-generator settings-validate # check every file that applies, and find entries that change nothing
ky-generator settings # what applies right now, and which file set it
ky-generator settings-set -key=options.addHeader -value=false
ky-generator settings-schema # the json schema, for editor completion
settings-validate is the one to run after editing a file by hand: it reports invalid json, unknown keys and values
that do not fit their option, and it exits non-zero on an error, so it works in a build pipeline. Entries whose value
would apply anyway are listed as removable.
root: true stops the search above the file it sits on. ignoreGlobalSettings: true additionally drops the
settings of the machine, for a repository whose generated output has to be identical everywhere - the id of the
installation stays in the application data folder either way, since it cannot change a generated byte.
See documentation for every option.
For a complete overview see our documentation
{ "$schema": "https://generator.ky-programming.de/v10/schema.json", "root": true, // stop the search for further files above this one "options": { "addHeader": false, "lintSuppression": { "typescript": "/* eslint-disable */" } }, "typescript": { "noIndex": true } }