-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C# generated code: exception classes are not created in subsequent references #4205
Comments
Bump - same issue here. Did you find a workaround? |
.NET's OpenAPI client generation has a concept of That makes sense to me, as I don't want a different type of exception for all client classes. In fact, I use my own exception class and never generate. You might try something like this: <ItemGroup>
<OpenApiReference Include="OpenApiReference/Service1_openapi.json" SourceUrl="http://localhost:5050/openapi.json">
<CodeGenerator>NSwagCSharp</CodeGenerator>
<ClassName>{controller}Service</ClassName>
<Namespace>Service1</Namespace>
<FirstForGenerator>true</FirstForGenerator>
<Options>/ExceptionClass:ServiceException /GenerateClientInterfaces:true /GenerateOptionalParameters:true</Options>
</OpenApiReference>
<OpenApiReference Include="OpenApiReference/Service2_openapi.json" SourceUrl="http://localhost:5051/openapi.json">
<CodeGenerator>NSwagCSharp</CodeGenerator>
<ClassName>{controller}Service</ClassName>
<Namespace>Service2</Namespace>
<Options>/ExceptionClass:ServiceException /GenerateClientInterfaces:true /GenerateOptionalParameters:true</Options>
<FirstForGenerator>true</FirstForGenerator>
</OpenApiReference>
<OpenApiReference Include="OpenApiReference/Service3_openapi.json" SourceUrl="http://localhost:5052/openapi.json">
<CodeGenerator>NSwagCSharp</CodeGenerator>
<ClassName>{controller}Service</ClassName>
<Namespace>Service3</Namespace>
<Options>/ExceptionClass:ServiceException /GenerateClientInterfaces:true /GenerateOptionalParameters:true</Options>
<FirstForGenerator>true</FirstForGenerator>
</OpenApiReference>
</ItemGroup>
<ItemGroup> But I'm not sure it would work. You have a very particular and odd use case here. It will work if you split your clients into different projects. Either way, I would recommend creating your own compatible exception and using that one in all clients. Use https://aka.ms/msbuildlog to debug your build. |
Thank you very much, @paulomorgado for your quick response. Adding I tried adding
I think the problem could be solved by tweaking the logic in
|
Have you tried How were you doing this before? Looks like you are trying to use |
Yes, adding Before, we where launching the nswag command from the console. What was never intended? If you mean that |
It was a long shot.
For the common use case of
Have you found any .NET documentation supporting your claims that this particular case should just work?
|
I've created #4668, but haven't tested it. Can someone test if the changes solve this issue? |
This has proven to be a hard to resolve issue, given the infrastructure provided by the .NET SDK and NSwag tooling. On the other hand, it is easy to customize and you can build your own for your own needs. When everything else fails: Exec task |
So, as far as I understand it - the conclusion is that
I may misunderstand something general about OpenApiReference - but on a "logic" level, I agree with @hmoratopcs: "I think the use case is pretty starightforward: add two references with different namespaces for each. This should "just work" Comment and ideas are welcome - as well as support for "just generating the exception class every single time". If possible, of course. I can't really decide if what @paulomorgado is saying is that this simply cannot be done due to other limitations outside of nswag. I hope not :) |
Have you tried |
No, I have not. Based on the original post from @null-d3v it doesn't look like it works:
I believe that part of my post was the "least interesting" :) What I find more relevant is the part of "how could it be fixed". Is it somehow "wrong" to just have the exception classes generated each and every time? It's inside the clients namespace anyway, so I don't really see issue. It would be precisely the same if I moved every client to its own project, but would cause more overhead. Maybe you could explain to me (since I obviously don't get it):
|
@janrhansen, it could be possible. After all, it's all software. Feel free to submit a PR. |
@paulomorgado Thanks.. The problem is (or may be) that I might be mistaken here. If the current behavior is in fact "correct", then submitting a PR with a change will probably break it for other users, which nobody wants. What I'm seeking is a confirmation that this is actually a "bug" (or, inconvenience) and as such someone could fix it - or a better understanding of how the tool is supposed to work, if it is not a "bug". Is there a reason for not generating the exception class every time. If there is, I probably shouldn't bother figuring out how to change this behavior :) If not, I will see if I can find time to help, but with two kids etc. this might not be anytime soon :) |
@janrhansen, nothing like a proof of concept to clear everyone's doubts. You have to take into account the development and maintenance costs and the percentage of users that require this and are blocked from doing it in any other way. |
When using multiple
OpenApiReference
s withNSwagCSharp
generation, exception classes are only generated for the first listed dependency.Example
ServiceException
definitions in theService2
andService3
generated files are absent, resulting in compiler failures for those two references. This cannot be rectified by explicitly usingGenerateExceptionClasses
; the exceptions will continue to fail to generate. Using{controller}
placeholders for the exception class also has the same result.The text was updated successfully, but these errors were encountered: