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.