Swagger-codegen: [Dotnet] Update RestSharp to latest version

[Elufimov]

The latest version of RestSharp support .NETFramework 4.5.2 and .NETStandard 2.0 out of the box.

[wing328]

@Elufimov glad to hear that. May I know if you've time to contribute the enhancement?

A good starting point is https://github.com/swagger-api/swagger-codegen/tree/master/modules/swagger-codegen/src/main/resources/csharp

[Elufimov]

If I will update restsharp to 106.1.0 it will raise runtimes versions to .NETFramework 4.5.2 and .NETStandard 2.0. Would it be fine?

[wing328]

Currently, the C# API client generator supports the following:

    targetFramework
        The target .NET framework version. (Default: v4.5)
            v3.5 - .NET Framework 3.5 compatible
            v4.0 - .NET Framework 4.0 compatible
            v4.5 - .NET Framework 4.5+ compatible
            v5.0 - .NET Standard 1.3 compatible
            uwp - Universal Windows Platform (IMPORTANT: this will be decommissioned and replaced by v5.0)

For version other than 4.5, I think we'll need to keep using the existing RESTSharp version.

(I'll file a PR to remove the uwp option)

cc @jimschubert @mandrean

[jimschubert]

@wing328 clarification: we don't support netstandard 2.0. That was just announced in August, and I haven't seen changes to add anything specific to the newer version.

Also, I have opened #7029 to discuss some issues with versioning of things like v5.0 referring to netstandard1.3 when it's meant to refer to PCL 5.0.

[albator1932]

Assuming RESTSharp should be in its last version to support .NET 4.5, I believe the version should be 105.2.3 instead of 105.1.0, right ?

EDIT: sorry, I forgot about that: https://github.com/restsharp/RestSharp/issues/742

[holger-romey]

I had the same problem and i will use my workaround to upgrade a generated WebApiClient up to .NetStandard2.0

1.) First of all generate the ApiClient with Swagger CodeGen with this options: "-l csharp" "-c $Config" where $Config is the reference to my configuration file (json). Within this configuration choose "targetframework" = "v5.0"
2) This options will create a .Net Standard 1.3 portable version of the Api client.
3) Beside of this generated project add a new empty project in .NetStandard2.0
4) add this nuget-packages:
► FubarCoder.RestSharp.Portable.Core (4.0.8)
► FubarCoder.RestSharp.Portable.HttpClient (4.0.8)
► Newtonsoft.Json (latest version)

5) copy the folders "Api", "Client", "Model" from the generated .NetStandard1.3-project to your newly created .NetStandard2.0 project.

6) change the Uri(s) in the "ApiClient.cs" to target your WebApi-Server.

7) build the new project and be happy to have a WebApiClient in .NetStandard2.0

I hope this is helpful for someone who needs to have the WebApiClient in .NetStandard2.0.

[jimschubert]

Looks like we'd need to use one version for .NET 4.5 and higher, but current version for .NET 3.5/4.0 support.

I'm working on a full refactor of the ApiClient and Configuration usage, making it easier for users to extend functionality without copying code around. This will allow users to implement HttpClient instead of RestSharp, for example.

I plan to have this fully documented either in the generated client README or a sibling markdown.

A possible workaround for now, as people regenerate clients, is to modify the package config and project file, then add them as an exclusion to .swagger-codegen-ignore so future generations don't overwrite the changes.

[jimschubert]

Also (sorry, can't edit my last comment on mobile) the newer version of RestSharp would mean our .NET 4.5 maps to 4.5.2. I don't know if that's a big deal, though.

If anyone wants to evaluate the client refactor I mentioned that I have in progress, let me know and I'll clean up my branch then link it here.

[holger-romey]

@jimschubert i think the .Net Framwork 4.0 => 4.6.2 is no big deal to handle with all the current and well known solutions. In my opinion its more important to have a solution for .NetStandard2.0 so developers are able to use this api clients in .Net Core environments.

Anyway i have one more question for you that i cannot solve on my own :-) it is possible to configure the WebApi-Servers Uri, so that will replace all the default entries (https://localhost) in the ApiClient.cs-file?

[wing328]

so that will replace all the default entries (https://localhost) in the ApiClient.cs-file?

In your spec, did you specify host and basePath?

e.g. https://github.com/OAI/OpenAPI-Specification/blob/master/examples/v2.0/yaml/petstore.yaml#L7-L8

localhost is used only when host, basePath are not defined if I remember correctly.

[holger-romey]

@wing328 I'm working with the CLI and i run a powershell script similar to this:
java -jar "D:....SwaggerCodegenswagger-codegen-cli.jar" generate -i $Source -l csharp -o $Output -c $Config

That means that the only option i have, is to use a configuration file to make some individual changes like this:
{
"packageName": "Pk.XXX.RestAPIClient",
"targetFramework": "v5.0"
}

I dont think that i can specify the host and the basepath there. So i'm looking for a solution to parameterize the host uri in the config file :-)

[wing328]

@holger-romey I'm referring to the OpenAPI/Swagger spec (JSON/YAML), not the config file (JSON) for customizing the output by Swagger Codegen

e.g. https://github.com/OAI/OpenAPI-Specification/blob/master/examples/v2.0/yaml/petstore.yaml#L7-L8

[wing328]

Also the base URL (host + basePath) can be modified during runtime for different environments (dev, test, QA, etc)

[Cloudmersive]

Any update on this? The old version of RestSharp is increasingly becoming a problem as this version is now very old.

[Cloudmersive]

@wing328 Any thoughts on this one?

[wing328]

@Cloudmersive thanks for tagging me but I'm no longer involved in this particular project so can't help with this issue.

[Cloudmersive]

Thanks. Any idea who might be working on this now @wing328 ?

[steffenh13]

Any news on this?

[mbedeker]

Any news on the .netstandard 2.0 support? still in the pipeline?

[jimschubert]

William and I no longer contribute to this project; I don't want the perception to be that maintainers are ignoring your requests, we just don't generally get them from this repo any longer.

We've forked this project at openapitools/openapi-generator, where we have .netstandard support and a large refactoring of the client which allows users to define their own accessor (instead of RestSharp).