Additional Namespaces Usages should be applied to the namespaces that the C# client generator uses

[daiplusplus]

In the current NSwag C# client generation template all types have fully-qualified namespace names, e.g.

var content_ = new System.Net.Http.StringContent(Newtonsoft.Json.JsonConvert.SerializeObject(dto, _settings.Value));

In NSwag.Studio I set "Additional namespace usages" to System.Net.Http,System.Threading.Tasks,Newtonsoft.Json in the expectation that this would cause the generated C# code to look like this instead;

var content_ = new StringContent(JsonConvert.SerializeObject(dto, _settings.Value));

...but it doesn't, because the namespaces are hardcoded in the C# templates:

If the aim is to ensure the types fully resolve then the generated code should use the global:: keyword like the VS2005 WinForms designer did.

I have other template changes I'd like to make, I'll be happy to submit a PR but because this enters opinionated programming territory I imagine the project owners are not very receptive to changes to those templates, or are they?

The changes I'd like to make include:

• Remove #pragma warning disable and generate code that doesn't generate warnings in the first place (and use specific targeted warning-disable pragmas, and/or make it an NSwag configuration option).
• Allow me to specify a base-class for the exception type.
• Use type-names instead of var.
• Read and deserialize responses with JsonTextReader instead of reading into a String first, which is faster and avoids extra string allocations (but retain the String version for debugging)
• Treat status codes as int not string (why does this happen?)
• Use using instead of trivial try/finally/dispose
• Use a single object deserialization method instead of the excessive amount of code duplication seen in every operation method.

My question:

• Would a PR with these changes be accepted?
• If not, would a PR that enables these changes as runtime configuration options be accepted?
• Finally, if not that, then a PR that makes the C# code-generation templates as runtime, user-editable templates?

Update:

I see NSwag.Studio has "Template directory" as an option but I can't see any documentation for it. The existing Issue is from 2016 and the wiki article even says it's outdated.

[RicoSuter]

The additional usages setting is mainly used to import DTO types when DTO generation is disabled.

Template directory is explained here: https://github.com/RSuter/NSwag/wiki/Templates

But i thinks most of your suggestions just make the default templates more robust.

Need to check your suggestions in detail...

Most import is that we dont break existing users...

[RicoSuter]

Similar issue, maybe we should sync, https://github.com/RSuter/NSwag/issues/1666

[aluitink]

I ran into a similar issue using the NSWagCSharp OpenApiReference CodeGenerateor via the csproj file.

I have my own DTOs so generating with /GenerateDtoTypes:false

I could not find an option that allows you to specify additional namespaces to be used in the generated client.

For anyone else that runs into this issue.. C# 10 supports global using that can mostly solve this.

Usings.cs:

global using TheNamespaceOf.YourDTOs;
global using Task = TheNamespaceOf.YourDTOs.Task;

^ I have a Task class that conflicts with the System.Threading.Tasks.Task class - override it this way.

The result is the Api Client is generated with the expected types that don't resolve, adding the global using allows it to compile.

(I realize C# 10 was released in 2021 some time after this issue was opened.. mentioning incase someone else lands here)

[IvanPranovich]

@aluitink found the way how to make it work

The parameter to add namespace using works. You could try <Options>/jsonLibrary:SystemTextJson /generateDtoTypes:false /AdditionalNamespaceUsages:"My.Namespace1,My.Namespace2"</Options>

The serialization problem that controllers usually use Camel Case. NSwag has default one with 1-1 mapping (first letter must be capital).

To change default serialization on controller side (.NET 7 Asp.net core):

builder.Services.AddControllersWithViews().AddJsonOptions(options `=>`
{
    options.JsonSerializerOptions.PropertyNamingPolicy = null; 
});