Request: support for C# .NET 3.5 client

[who]

Currently, the C# generator in swagger-codegen conforms to .Net 4.5+.

It would be nice to have a .Net 3.5 compatible generator, so that the resulting DLL could be used in places where .Net 4.5 functionality is not possible.

[wing328]

@who thanks for the feedback. Do you mean updating the existing C# client to make it backward compatible with .Net 3.5 framework ?

[who]

@wing328 That is one way to do it, yes, but the existing C# client uses many language features that don't translate back to 3.5 very well, so this could be tricky.

[wing328]

@who if you can give me a bit more direction on what feature is not available in 3.5, I can start updating the template during weekend.

[who]

@wing328 The biggest difference is the lack of Task, await, and easy async support in 3.5. Also, dynamic type is not supported in 3.5. There are some libraries that will be able to support these missing features as a NuGet packages, but this won't be a complete solution. Additionally, RestSharp is compatible with 3.5, but only the 4.0 version contains RestClient.ExecuteTaskAsync, which the existing C# swagger-codegen client uses heavily. Because of this, adding 3.5 support to the existing template might change it significantly, to the point where creating a separate template may be preferred.

I am going to fork and start working on a PR, but I could use some help if you'd like to collaborate.

[who]

@wing328 It looks like this PR broke .Net 3.5 compatibility: #809

[who]

I have filed a question regarding Async capabilities in Resharper when using augmented .Net 3.5 here: restsharp/RestSharp#718

[who]

Update from @hallem (RestSharp dev)

The short answer is no, the Async support in RestSharp requires .Net 4.0+

See: restsharp/RestSharp#718

[wing328]

@who thanks for following up with RestSharp dev. In this case, I would agree with your suggestion earlier to add a separate generator for C# .net 3.5.

[who]

@wing328 Agreed; a separate generator is the solution. I actually put some work into implementing 3.5 support in the existing templates, but found that it required too many "if .net 3.5" and "if not .net 3.5" conditionals.

[wing328]

Thanks @who. I've added unit testing for Petstore C# client: https://github.com/swagger-api/swagger-codegen/tree/develop_2.0/samples/client/petstore/csharp/SwaggerClientTest. You might find it useful in testing the C# .net 3.5 client that you're working on (likely you will need to remove the test cases for async method call)

If you need any help or feedback, please let us (community) know. Once again thanks for your contribution!

[who]

@wing328 The original intent I had for this request was to use swagger-codegen to generate .Net 3.5 managed libraries that I can use in Unity3D. However, as it turns out, the maximum .Net version supported for managed libraries in Unity3D is .Net 2.0.

Therefore, I will also be making a .Net 2.0 generator specifically for use as a Unity3D library generator.

[jimschubert]

@wing328 @who Have either of you started any work on this?

I've actually experienced the same issue, but had no problem updating my libraries to .NET 4.5.2. I'd like to eventually revert those libraries back to .NET 3.5, because they'll at some point need to be consumed by a desktop application with Windows XP support. I'd be happy to start work on this issue.

Are there any existing examples of how swagger-codegen handles a base language implementation (other than DefaultCodegen)? I could see where CsharpDotNet2ClientCodegen and CSharpClientCodegen could be refactored to use a common base. This would easily allow for additional 'language' support of .NET core, Windows Phone, Universal Windows Platform, and other generators that wouldn't currently be easily maintained as separate types (see: dotnet/corefx...standard-platform.md).

I think #1889 plays a big part in this issue.

[wing328]

@jimschubert I do not have a chance to work on this.

I agree with you that CsharpDotNet2ClientCodegen and CSharpClientCodegen could be refactored to use the same abstract base class similar to AbstractTypeScriptClientCodegen for typescript angular and node generator.

[jimschubert]

@wing328 Cool. I'll take a look at the typescript abstraction and start working on this NET 3.5 client.

[jimschubert]

This feature should be complete. Pass -DtargetFramework=v3.5 to generate .NET 3.5 client.

[tgraupmann]

Is there a command-line option that can unset a property {{^netStandard}}? I'm trying to backport some things to .net 2.0 before net standard...

[jimschubert]

@tgraupmann If you pass -DtargetFramework=v3.5, you get the 3.5 code and not the .NET Standard changes.

There's a .NET 2.0 generator. Any reason you're not using that? Or are you working on merging it to the main csharp generator?

[jimschubert]

Also, {{^netStandard}} means "netStandard is not set". Code on this block will be 3.5 by default, or 4.x or uwp depending on the options you've passed.

[tgraupmann]

Csharp .Net 2.0 generate lacks enum type support. It's coming in as a string versus the later exporter has a nice type. I'm manually merging as I remove some netstandard features. This is to work with Unity. Here's my Swagger definition with some enums for testing with .Net 2. https://raw.githubusercontent.com/tgraupmann/ChromaSwaggerDefinition/master/api/swagger/swagger.yaml You'll see EffectType comes through as a string instead of an enum.

For enum {{{value}}} it has quotes around it. There doesn't seem to be a way for mustache to remove quotes from a string...

https://github.com/swagger-api/swagger-codegen/blob/master/modules/swagger-codegen/src/main/resources/csharp/modelEnum.mustache#L13

toEnumValue added quotes around the enum where that should have been handled by the template.
https://github.com/swagger-api/swagger-codegen/blob/master/modules/swagger-codegen/src/main/java/io/swagger/codegen/languages/CSharpClientCodegen.java#L559

[wing328]

toEnumValue added quotes around the enum where that should have been handled by the template.

We add the quotes for string but not numeric value. This is to make sure both string and numeric enum are supported.

If C# .net 2.0 generators support enum, would that meet your requirement?