NSwagStudio C# client generation issues

[IanKemp]

Tool itself:

1. There is no option to generate client methods as synchronous (or at least I was unable to find it).
2. No provision for inputting credentials if the swagger.json is protected by HTTP authorisation.

Generated code:

1. news up System.Net.Http.HttpMethod instances instead of using the appropriate static properties on the HttpMethod class.
2. Converts the HTTP response code to an int, then a string and does string comparisons... but the response code is already a strongly-typed System.Net.HttpStatusCode. I suppose this could be useful if the server you're talking to returns nonstandard status codes, but even then, I'd just keep it as an int.

[RicoSuter]

1. Currently there is no option for that

2. You have to provide a base class and set the headers in the CreateHttpRequestMessageAsync method. This is on purpose so that you have full control over the authentication process of the client.

3. This is the simplest way to do this, because the HTTP method is specified as string in the spec. We could change that

4. Same here: The status code is a string in the spec, this is why we have this conversion...

Please create new issues for each item and/or create a PR to fix them...

[Emasoft]

About number 2: can you at least provide a working example of this basic class?

[RicoSuter]

I hope I get the time to write articles about this topic soon

[IanKemp]

@RSuter

Re (3), while it is correct that the HTTP method is a string and anyone can add their own arbitrary one, it makes sense IMO to use references to the static readonly HttpMethod instances if possible - thereby reusing them, instead of creating and allocating a new instance each time.

Re (4), please refer to the RFC. The Status: header is a string of the form <status-code><whiiespace><status-code-description>, where <status-code> is guaranteed to be an integer by the HTTP specification. <status-code> is the portion that is referenced by HttpResponseMessage.StatusCode property, which is why it is valid to reference it as an int.

I also have another:

5. Don't construct and dispose HttpClient instances; create one instance and reuse it, as per https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/ and numerous other references.

I will see if I can get around to throwing together a PR for these; unfortunately I'm without Internet at home right now so it's difficult.

[IanKemp]

Hmmm. The NSwag.CodeGeneration* projects target .NET Standard 1.0 which means that I can't include the System.Net.Http NuGet package, which means I can't inspect System.Net.Http.HttpMethod's members to determine if the supplied HTTP method is one of the known/predefined ones.

This is solved by changing the project to Profile 111 (netstandard 1.1), but that entails losing Windows Phone Silverlight 8.0 support... dunno how much of an issue that is.

[mchadrdk]

I would say leaking connections is a larger issue than losing Windows Phone Silverlight 8.0 and 8.1 support.

[Emasoft]

@mchadrdk I agree. The default code should work using the most stable architecture.

[bobend]

@mchadrdk /InjectHttpClient:true seems to be solution to that problem.
But agree that should be the default value.

[RicoSuter]

InjectHttpClient will be set to true by default in the next major version (breaking change): #984