quino generate

Examples

The following commmand generates code for the Core, Invoice and Main modules in the ProductApplication from the Product.Model.dll assembly to src/Product.Core/Model.

quino generate -i out/Product.Model.dll -o src/Product.Core/Model -a ProductApplication -m Core,Invoice,Main

Purpose

Quino products include a model. Most products will want to generate business and metadata objects from this model. See [../metadata/generatedCode.md] for more information.

Function

Anyone can use this tool to generate the business and metadata objects for a product model.

Command line

The command can be controlled with the following additional parameters.

Name	Values/Example	Description
-a, --application	Sandbox	The name of the application
-h, --help		Shows the full command-line help
-i, --input	../out/Sandbox.Core.dll	Path and filename of the assembly containing application
-m, --modules	Core,Invoice,Accounts,Product	A comma-separated list of modules to generate
-o, --output	packages	The path to the output folder
-p, --preview		A flag that indicates a test run that does not write to the output folder

If the application parameter is omitted, the tool will let the user choose from the applications available in the input assembly.

Example

In our Sandbox project we're using dotnet quinogenerate to generate our model on a successful build.

We've the following script in the post-build:

dotnet tool install dotnet-quinogenerate --tool-path $(ProjectDir).tools --version 6.0.0-master3178

.\.tools\dotnet-quinogenerate -i $(SolutionDir)..\out\$(TargetFileName) -o $(SolutionDir)libs\Sandbox.Model.Generated\ -m SandboxApplication --legacy false

• The first line installs the specific preview version from our nuget feed.
• The second one generates the model based on our configuration.

Troubleshooting

How do you provide services to the code-generator?

tl;dr: Make sure that code-generation uses a product's *Application rather than *ModelBuilder. One way to do this is to simply pass e.g. Sandbox for the -m parameter, so the code generator finds the SandboxApplication first. Passing SandboxApplication also works.

Even if you've included the service in your application, you may still encounter a problem when generated code. The problem crops up when generating code using only the *ModelBuilder instead of the *Application.

What's the difference? To answer that, we need to look at how the code generator works. The code generator is a Quino application in its own right, but it doesn't have its own model. It has the services to load and generate code from a model.

If your model is very simple and doesn't inject anything other than the services already available in the code generator, then you can technically generate from just the *ModelBuilder. A module like e.g. Reporting, however, depends on the IReportImageFactory, which isn't included in the code generator. As soon as you use Reporting, you must generate code using the *Application instead.

When you use the *Application to generate code, instead of creating your model builder and asking for its model, the code generator creates your application and asks for its model. The difference is that your application registers all of the services necessary to build your model, including the IReportImageFactory.

Even if you can technically build using only the model generator, it is strongly recommended to use the application to generate code. Even if the generator already has all of the services it needs to generate code for your model, it is using its own versions of those services. If your application overrides any of these services, they won't be used by the code generator if you don't give it the whole application. This may or may not matter at first, but can eventually lead to subtle code-generation issues.