If you have two OpenApiReferences, and either of them has /WrapResponses:true set, then all but the first call to openapi2csclient will automatically include /generateResponseClasses:false at the end. Now if only the second one of them contains /WrapResponses:true, the SwaggerResponse classes will not be generated at all and the code ends up not compilable.

If you switch the order around so BarClient is generated first, everything works fine because now FooClient is generated without the SwaggerResponse classes, which it didn't need anyway. However, what is impossible currently to get working is to have /WrapResponses:true on BOTH of them, because then the second one doesn't generate its own response classes, and because it's in a different namespace it will not see the response classes of the other one. You can also not manually add generateResponseClasses:true because then you get "unrecognized arguments are present" error because now the config option is present twice in the call to openapi2csclient. So you would manually need to add AdditionalNamespaceUsages to the first one's Namespace or other shenanigans.

Version of NSwag toolchain, computer and .NET runtime used

NSwag.ApiDescription.Client 14.6.1

To Reproduce

Minimal .csproj example:
<OpenApiReference Include="foo.json" ClassName="FooClient" CodeGenerator="NSwagCSharp" Namespace="SomeNamespace"/> <OpenApiReference Include="bar.json" ClassName="BarClient" CodeGenerator="NSwagCSharp" Namespace="OtherNamespace" Options="/WrapResponses:true"/>

Expected behavior

FooClient is generated with the default options, BarClient is generated with /WrapResponses:true but NOT with generateResponseClasses:false

Generally: openapi2csclient should be called with the specified options, not additional ones.

Additional context

This bug is very similar to #4890 and is likely because of the same underlying issue.

I am using NSwag.ApiDescription.Client to generate multiple client classes in the same .csproj file. Since I updated from 13.20 to 14.6.1, I have experienced various oddities around the generated classes being generated with different options than I had specified explicitly in my .csproj file. This very different behavior has not yet been documented in the breaking changes, despite a bunch of bug reports being caused by them (e.g. #4938, and the fixed #4890).

The underlying issue seems to be that now NSwag tries to be "clever" with how it calls openapi2csclient and adds additional configuration options that have NOT actually been specified by the user. And frankly, this design decision makes zero sense at all and in my opinion should be removed again, or at least possible to disable, because you now have to jump through so many hoops to get this working, and really closely study that openapi2csclient is now called with different options than you specified. Which, from what I found, isn't even documented anywhere!

@bkoelman I understand that it maybe was annoying to first-time users that the exception classes would be generated multiple times by default, but solving that isn't hard, there is a specific config option for that. Now you turned it upside down and introduced breaking changes to all long-time users, which now have to figure out how to change their .csproj file, and dig deep to understand that openapi2csclient is called with different options than those they explicitly specified. The openapi2csclient output is also completely not helpful to this ("Unrecognised arguments are present").

Now instead we have to contend with a situation where the options we actually give aren't actually honored anymore. You have removed control over the options from developers, where developers should actually have full control over which options we generate our client classes with. If there at least was an option to disable this kind of "let's behave differently on the non-first OpenApiReference" shenanigans, okay - but currently there's not...

Also note that now, any reordering of the OpenApiReference tags in the .csproj files can easily lead to breakage; and what's worse, breakage that a developer usually will not even notice on their own machine, everything will compile fine because the Client isn't regenerated on build just because of the reordering in the .csproj file, but then you push your changes and it's not compilable for others. In my opinion it's just not a good design when the order matters, the OpenApiReferences should be seen as independent and the developer has the job of joining them together if they want to.