Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CS0649 due to _baseUrl instead of BaseUrl from 14.0.2 => 14.0.[3-7] #4854

Closed
martindamgaardlorensen opened this issue Apr 11, 2024 · 3 comments

Comments

@martindamgaardlorensen
Copy link

martindamgaardlorensen commented Apr 11, 2024

I have a working setup with 14.0.2 with the following settings:

"codeGenerators": {
    "openApiToCSharpClient": {
      "clientBaseClass": "ApiClientBase",
      "configurationClass": "IApiClientConfiguration",
      "useBaseUrl": true,
      "generateBaseUrlProperty": false,
      ...
      }
   }

The ApiClientBase class contains a protected string BaseUrl { get; } property which is set in the constructor with a value obtained from the IApiClientConfiguration passed in the constructor.

However, when upgrading to 14.0.3 (or any thing else up to latest 14.0.7), the generated code now contains a private readonly string _baseUrl field (which is used instead of the BaseUrl property in the base class) which is never initialized so I get a CS0649 error when building it - and if I disabled that somehow, the code would still not work as the base url would not be set.

I see no documentation about this breaking change and have been unable to find reasonable way to mitigate this.

I could probably add an abstract method in ApiClientBase that I would invoke from the constructor in the same class (if I disable warnings about virtual methods called from constructor is unsafe) and implement that method to set _baseUrl field from BaseUrl property in a partial hand-coded class alongside the generated code. But that sounds wrong in multiple ways.

What is the intensions with this changed behavior? Or is this a bug?

@martindamgaardlorensen
Copy link
Author

Just noticed that this is probably a duplicate of #4764.

@olegd-superoffice
Copy link
Contributor

@martindamgaardlorensen it is a duplicate indeed. Maybe close this and add a comment on that bug instead?

@martindamgaardlorensen
Copy link
Author

Duplicate of #4764.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants