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

Regression - generated class names are not unique #5019

Open
erictrigo opened this issue Nov 11, 2024 · 0 comments
Open

Regression - generated class names are not unique #5019

erictrigo opened this issue Nov 11, 2024 · 0 comments

Comments

@erictrigo
Copy link

Steps to reproduce

  • have an OpenAPI spec that includes multiple schemas defined under components.schemas with names containing periods and ending with numbers, e.g.:
    • "Section.TestClassA.1"
    • "Section.TestClassA.2"
    • "Section.TestClassB.1"
    • "Section.TestClassB.2"
  • use NSwag to generate a C# client

Observed behavior

  • with NSwag versions up to and including 14.0.0-preview008:

    • generated class names are _1, _2 for the first set and _12, _22 for the second set
    • the client code compiles and is usable by application code
  • with NSwag version 14.0.0-preview009:

    • generated class names are _1, _2 for both sets
    • the client code compiles but is not usable by application code due to improper re-use of class names
  • with NSwag version 14.1.0:

    • generated class names are _1, _2 for the first set and 1, 2 for the second set
    • the client code does not compile due to invalid class names (can't be a number)

Expected behavior

  • the behavior from NSwag 14.0.0-preview008 and earlier, where all generated class names are unique

Sample repo

I have prepared a minimal sample repo here that demonstrates the problem. Build the solution in the repo to automatically generate clients using various NSwag versions.
The correctly working versions of NSwag generate clients with classes named _1, _2, _12 and _22. The NSwagExample.Consumer project references these classes for each project, in their corresponding Consumer.cs file.

Observed behavior per project:

NSwagExample.13.20.0.And.NSwag.Net60.OK

Versions
NSwagExe -> Net60
NSwag.MSBuild -> 13.20.0

  • No compilation errors in the project.
  • Uncommenting the NSwagExample.Consumer\13.20.0.And.NSwag.Net60\Consumer.cs file displays the expected behavior in all versions: _1, _2, _12 and _22 exist and can be referenced without issues. OK.

NSwagExample.14.0.0-preview008.And.NSwag.Net80.OK

Versions
NSwagExe -> Net80
NSwag.MSBuild -> 14.0.0-preview008

  • No compilation errors in the project.
  • Uncommenting the NSwagExample.Consumer\14.0.0-preview008.And.NSwag.Net80\Consumer.cs file shows that the behavior has not changed yet: _1, _2, _12 and _22 exist and can be referenced without issues. OK.

NSwagExample.14.0.0-preview009.And.NSwag.Net80.NOK

Versions
NSwagExe -> Net80
NSwag.MSBuild -> 14.0.0-preview009

  • No compilation errors in the project.
  • Uncommenting the NSwagExample.Consumer\14.0.0-preview009.And.NSwag.Net80\Consumer.cs file shows the first change in behavior: _12 and _22 do not exist anymore, and instead _1 and _2 are reused twice. Not OK.

NSwagExample.14.1.0.And.NSwag.Net80.NOK

Versions
NSwagExe -> Net80
NSwag.MSBuild -> 14.1.0

  • There are compilation errors in the generated client due to the _12 and _22 classes being now named 1 and 2, which is not valid C# syntax. Not OK.
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

1 participant