The following commmand generates code for the
Main modules in the
ProductApplication from the
Product.Model.dll assembly to
quino generate -i out/Product.Model.dll -o src/Product.Core/Model -a ProductApplication -m Core,Invoice,Main
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.
Anyone can use this tool to generate the business and metadata objects for a product model.
The command can be controlled with the following additional parameters.
||The name of the application|
||Shows the full command-line help|
||Path and filename of the assembly containing application|
||A comma-separated list of modules to generate|
||The path to the output folder|
||A flag that indicates a test run that does not write to the output folder|
application parameter is omitted, the tool will let the user choose from the applications available in the
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.
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
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
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
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.