.Net 9 Support

[winromulus]

Hi,

Any chance of getting a NSwagExe_Net90 version soon? (even without any other changes).
Currently we have to install .net 8 in the docker images in order to produce the client which adds a lot of build time.
I couldn't find an issue for this or something mentioning .net 9 so I opened this one. Please feel free to close and link to an existing issue if there is one.

Thanks!

[vvdb-architecture]

Hear hear.
Even recompiling with the latest versions of the dependencies ( Namotion.Reflection et al.) would be an improvement and would correct issues like #4842 without breaking a sweat.

There are also 106 open pull requests. That's not a great motivation to add more. Yet, NSwag is still the best tool to generate code from OpenAPI, far superior than Kiota. It's disheartening to see even the low hanging fruit is left to rot.

[timohermans]

Seeing that the last commit is 4 months ago, I have a big feeling this project is slowly dying. I do hope that we get .NET 9 support soon though. But yeah, my hopes are sinking :(

[dylanvdmerwe]

The net8 upgrade was quite rough. Let's hope net9 is smoother.

[Tragedie-v-JZD]

Just.. now noticed, that although complete solution is already switched to net9, nswag executes as part of build (I have it as custom msbuild task in CSPROJ) and regenerates clients as expected. (on computer, both sdks are installed).

Regardless of that, I am considering switch to native Microsoft.OpenApi / Kiota as part of update to .NET 9 for these API client generation stuff).

[RicoSuter]

Maintainer here, will add .NET 9 support in the next days. Really need to do a feature gap analysis of new OpenAPI support and NSwag and then see what the next steps are.. motivation is not very high knowing that NSwag essentially has to compete with MS or slowly die..

[xC0dex]

Hey @RicoSuter,

Allow me to share my thoughts on this topic.

First of all
NSwag is a fantastic tool, and we use it extensively at work. It's been a fundamental part of our development process, and we deeply appreciate all the effort you and the community have put into maintaining it over the years. That said, I completely understand that the motivation can be low.

The Microsoft.AspNetCore.OpenApi package
From my perspective, the Microsoft.AspNetCore.OpenApi package still lacks some features. Until these gaps are addressed, I believe many teams, including ours, won't switch to the built-in solution.

Thoughts on NSwag's Future Focus
The API client generation in NSwag is truly excellent, and it’s one of the tool's standout features. In my opinion, it would make sense to focus on this strength:

• Continue enhancing the client generation tools.
• Perhaps even provide transformers or extensions to improve the experience when working with Microsoft.AspNetCore.OpenApi. This way, NSwag could complement the ecosystem rather than competing head-on.

Streamlining the Project
One thought I had: It might be worth considering ways to streamline the project. For instance, I thought about contributing a pull request for .NET 9 support, but wasn’t sure where to start. The scope of the project is impressive, but it can also make contributing a bit challenging for newcomers.

I hope these thoughts don’t appear presumptuous. Thanks again for all your work on NSwag!

[RicoSuter]

@xC0dex thanks for your reply. I also think this is the way forward, e.g. start with NSwag.Extensions (.NET 9 only and provide missing features as extensions) to ensure that we can quickly migrate to MS impl for spec generation and focus on the code generators only long-term. I'm just a bit afraid that a lot of things are not (correctly) implemented yet (tuples, inheritance, nullable, etc.).

@lahma thanks for the PR, just wanted to start.
Will start at the bottom and work up today (Namotion.Reflection => NJsonSchema => NSwag).

[xC0dex]

@RicoSuter I’m glad you share this idea! I’d be happy to contribute and help out.
For .NET 10, the AspNetCore team is also planning improvements to the Microsoft.Extensions.ApiDescription.Server package. It might be worth considering building on top of the next version (.NET 10) of the OpenAPI stack, as they’re likely to address and enhance several aspects. So there would also be enough time to build this new library.

[RicoSuter]

.NET 9 support added with v14.2.0, now testing against real-world projects... please report problems here.

[winromulus]

@RicoSuter I updated NSwag.MSBuild to 14.2.0.0 and running am running:

<Exec
	Command="$(NSwagExe_Net90) aspnetcore2openapi /nobuild:true /project:Api.csproj /output:../Api.Client/document.NSwag.Generated.json /documentName:latest /configuration:$(Configuration)" />

Output gives:

Application references version '14.1.0.0' of 'NSwag.Core' which is lower than the required version '14.2.0.0'.

I don't have a reference to it (still digging), the only reference I have is to: Include="NSwag.AspNetCore" Version="14.2.0" . Could this be from the tooling?

[lahma]

@winromulus can you run dotnet nuget why NSwag.Core (tweak arguments if needed) and try to obtain info.

[winromulus]

Found the issue (local nuget cache). All good, all client and build tools ported. Thank you very much @RicoSuter !

[RicoSuter]

Can also confirm my SLN with 300+ projects and 10+ NSwag.Build based project successfully migrated (other NSwag unrelated problems remain :-)).

[vvdb-architecture]

Upgraded one of 2 nontrivial projects here, and all is well.
The second project needed to have a workaround outlined in #4842 and since the dependent packages were updated, this should not be necessary anymore. I've asked the team to verify this and will keep you informed. If it verifies, the issue can be closed.
My heartfelt gratitude goes out to you, @RicoSuter .

[KirkMunroSagent]

Hey @RicoSuter,

Allow me to share my thoughts on this topic.

...

Thoughts on NSwag's Future Focus The API client generation in NSwag is truly excellent, and it’s one of the tool's standout features. In my opinion, it would make sense to focus on this strength:

• Continue enhancing the client generation tools.

...

I hope these thoughts don’t appear presumptuous. Thanks again for all your work on NSwag!

Very well said, and I completely agree.

@RicoSuter: We use the client generation functionality in nswag heavily, and I don't see that changing with the .NET 9 OpenApi enhancements. To help keep your motivation up, and to help keep pushing NSwag forward while you streamline the focus, maybe you should require PRs to indicate if they're for the focus areas such as client generation (e.g. #4994), so that you can more easily identify those in the pool of open PRs you receive and use those to help move the unique value that nswag still provides forward with less effort.