Open AtosNicoS opened 4 years ago
The way I solved this was by specifying a templates folder and modifying the templates in that folder that I wanted to change. Specifically, make a change for public abstract class (which I think should be the default btw)
./templates/aspnetcore/2.1/controller.mustache
... namespace {{packageName}}.Controllers { {{#operations}} /// <summary> /// {{description}} /// </summary>{{#description}} [Description("{{description}}")]{{/description}} [ApiController] public **abstract** class {{classname}}Controller : ControllerBase{{#interfaceController}}, I{{classname}}Controller{{/interfaceController}} { {{#operation}} /// <summary> /// {{#summary}}{{summary}}{{/summary}} /// </summary> {{#notes}}/// <remarks>{{notes}}</remarks>{{/notes}}{{#allParams}} /// <param name="{{paramName}}">{{description}}</param>{{/allParams}}{{#responses}} /// <response code="{{code}}">{{message}}</response>{{/responses}} [{{httpMethod}}] ...
Then generated my output
java -jar ./swagger-codegen-cli.jar \ generate \ -i ./api.yaml \ -l aspnetcore --aspnet-core-version 2.1 --interface-controller \ -t ./templates/aspnetcore --template-engine mustache -c ./config.json \ -o ../
my config.json
`{ "packageName": "Api", "modelPackage": "Api.Models", "apiPackage": "Api.Api", "invokerPackage": "Api", "interfaceOnly": true
}`
In the end we now do not use the generator at all. It does not look production ready yet, so we implement all rest calls manually. Aspdotnet already has so much stuff builtin, that it is not really much more work. But we can remove all the swagger stuff and simply host the predefined yaml file ourself within the aspdotnet server. Another advantage is, that we can now use aspdotnet 3.1, which enables c#8 support and other features.
@copperorange thanks for the hint anyways, I've used your idea to also fix the generated client. This one also uses an outdated rest nuget package, that I've fixed locally. It seems that the overall c# tooling is really bad, unfortunately.
@AtosNicoS Agreed on all points. That being said we really like the continuous contract-first approach and met in the middle. Overridablitiy somewhat allows this and it seems all languages if supported should have an option to choose the class implementation methodology. Basically we changed all templates to generate the code we wanted. It does feel like there is an opportunity to carefully craft a template that meets all needs and catch up on the 3.1 support. In other cases just maintaining the .swagger-codegen-ignore or limiting to models also meets the objective.
Description
I want to write a yaml OpenAPI specification and generate a c# client and server from it (I do not want to generate the yaml for the c# server code.).
The code generator generates something similar to this:
What I want to do is to Not touch anything of the generated code, inherit this class and implement it:
But I will get an error, that the path/route is used twice:
Now my Question is: How can I properly override those methods without getting this error? If I change the methods from virtual to abstract, remove the (not relevant, generated) "implementation", the error disappears.
Swagger-codegen version
3.0.15 Windows
Command line used for generation
Suggest a fix/enhancement
There is very likely something I am not aware of yet, but if that is not the case, we could maybe also provide an abstract option to generate. The interface-only option does not contain any path definitions, so that is not a suitable option.