Skip to content

Support .NET 10 #3283

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

Draft
wants to merge 73 commits into
base: master
Choose a base branch
from
Draft

Support .NET 10 #3283

wants to merge 73 commits into from

Conversation

martincostello
Copy link
Collaborator

@martincostello martincostello commented Mar 2, 2025

Add support for .NET 10 and update Microsoft.OpenApi from v1 to v2.

This was started from #3252 and is very much a work-in-progress at this stage. The tests need more work to get them passing.

The general idea is to factor out any differences into shared helped classes that can be used to localise the Microsoft.OpenApi differences to as few places as possible. Once this gets further along, some of these changes can be cherry-picked into a new branch and merged into the default branch to minimise the diff for adding .NET 10 support. #3285

TODO

Before merge:


Prerelease builds from this PR can be consumed from MyGet:

<PackageReference Include="Swashbuckle.AspNetCore" Version="9.0.0-pr.3283.*" />
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="domaindrivendev" value="https://www.myget.org/F/domaindrivendev/api/v3/index.json" />
    <add key="NuGet" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
</configuration>

@martincostello martincostello added dependencies Pull requests that update a dependency file .NET Pull requests that update .NET code version-major A change suitable for release in a major version labels Mar 2, 2025
@martincostello martincostello added this to the Future milestone Mar 2, 2025
Comment on lines 11 to 14
<!-- TODO Workaround for error generated by https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview1/aspnetcore.md#improvements-to-integration-testing-of-apps-with-top-level-statements -->
<PropertyGroup Condition="$([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net10.0'))">
<NoWarn>$(NoWarn);CS1591</NoWarn>
</PropertyGroup>
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

martincostello added a commit that referenced this pull request Mar 3, 2025
Cherry-pick refactoring from #3283 to make multi-targeting easier for ASP.NET Core 10 and Microsoft.OpenApi v2.
@martincostello
Copy link
Collaborator Author

Some of the failing tests are microsoft/OpenAPI.NET#2109.

Probably need to wait until .NET 10 preview 2 updates to a newer version of Microsoft.OpenApi to ingest any fixes.

@martincostello
Copy link
Collaborator Author

Moved some of the changes into #3286 so we can prepare users for the change and also then change this PR to remove SerializeAsV2 completely.

@captainsafia
Copy link
Collaborator

@martincostello It seems like based on this changeset Swashbuckle.AspNetCore will have a similar constraint to Microsoft.AspNetCore.OpenApi in that OpenAPI 2.0 is only used for .NET 10+ above.

Any thoughts about figuring out a way to support 2.0 in .NET 8 and .NET 9?

@martincostello
Copy link
Collaborator Author

Not yet - I figured I'd start with the "easiest" option and get everything compiling and passing to unblock any apps using .NET 10, and then go from there.

I'm going to do some more work on this tomorrow(?) probably to try and get the tests passing, though I imagine I'll have to rejig a bunch of stuff next week anyway when 10.0.0-preview.2/2.0.0-preview7(?) ship.

Ideally OpenAPI 3.1 can be made available for our 8 and 9 users, but I'm slightly wary of the bigger "compatibility cliff" that creates with all the breaking changes and any other libraries that might extend Swashbuckle.

Good job there's another 7-8 months left to work that out on our side 😆

@codecov-commenter
Copy link

codecov-commenter commented Mar 5, 2025

Codecov Report

Attention: Patch coverage is 96.56160% with 12 lines in your changes missing coverage. Please review.

Project coverage is 94.06%. Comparing base (3390173) to head (6c30f2c).

✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
...ggerGen/SchemaGenerator/OpenApiSchemaExtensions.cs 80.64% 6 Missing ⚠️
...re.SwaggerGen/SwaggerGenerator/SwaggerGenerator.cs 96.70% 3 Missing ⚠️
....AspNetCore.Annotations/AnnotationsSchemaFilter.cs 92.85% 1 Missing ⚠️
...NetCore.ApiTesting/JsonValidation/JsonValidator.cs 66.66% 1 Missing ⚠️
...shbuckle.AspNetCore.ApiTesting/RequestValidator.cs 90.90% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #3283      +/-   ##
==========================================
+ Coverage   93.55%   94.06%   +0.50%     
==========================================
  Files         110      110              
  Lines        3834     3858      +24     
  Branches      719      767      +48     
==========================================
+ Hits         3587     3629      +42     
+ Misses        247      229      -18     
Flag Coverage Δ
Linux 94.06% <96.56%> (+0.50%) ⬆️
Windows 94.06% <96.56%> (+0.50%) ⬆️
macOS 94.06% <96.56%> (+0.50%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@martincostello
Copy link
Collaborator Author

Issue discovered via martincostello/aspnetcore-openapi#231 is that in some cases schema references go missing (like this one).

I'm not sure why and there's been a lot of API changes in that area since 2.0.0-preview5, so will have to wait until I've reacted to whatever changes ASP.NET Core 10 preview 2 brings and go from there.

@martincostello
Copy link
Collaborator Author

martincostello commented Mar 5, 2025

Also, preview5 => preview6 brings in more huge breaking changes (OpenApiSchema becomes IOpenApiSchema and causes OpenApiReference.Schema to no longer work) so that might force our hand on whether we do multi-targeting or not, as it might cause an explosion of #if directives and make the code too hard to deal with the differences between v1 and v2. It's especially difficult as those types come out of our public API surface, so it's not just an internal implementation detail we can work around like with JsonSchemaType/string.

@captainsafia
Copy link
Collaborator

@martincostello Yes, I should've warned you that the preview6 breaking changes are a bit of a pain to wrangle. Here's the PR where I did it for ASP.NET Core in case it is helpful (dotnet/aspnetcore#60269). The code surface in ASP.NET Core is admittedly smaller so most of the changes needed to be made in tests where I took shortcuts and used explicit casts for things I knew should be OpenApiSchemaReference for example.

OpenApiSchema becomes IOpenApiSchema and causes OpenApiReference.Schema to no longer work

You've probably already gleened this from the implementation, but OpenApiSchema with a Reference becomes OpenApiSchemaReference. You should be able to resolve the properties on it directly and OpenAPI.NET will resolve to the underlying target.

This is assuming that the reference has been correctly initialized in the OpenAPI document's workspace. Here is an extension method that I wrote in ASP.NET Core to help with this registration.

@martincostello
Copy link
Collaborator Author

Thanks for the pointers @captainsafia - I'll use those for reference once I start reacting to 10.0.0-preview.2 changes 🙇

martincostello added a commit that referenced this pull request Mar 18, 2025
- Cherry-pick refactoring from #3283 to make multi-targeting easier for ASP.NET Core 10 and Microsoft.OpenApi v2.
- Make Verify snapshots unique per target framework. This is to when .NET 10 introduces OpenAPI 3.1, it doesn't cause issues with the snapshots being intentionally different.
- Apply IDE suggestion to use collection expressions.
- Shorten test names to avoid `MAX_PATH` issues on Windows in GitHub Actions.
- Bump coverlet, Microsoft.NET.Test.Sdk, ReportGenerator, and xunit to their latest stable versions.
- Update more NuGet package version overrides for tests to the latest versions.
- Drop leftover `net6.0` reference in tests.
- Add support for ASP.NET Core 10 and Microsoft.OpenApi v2.
- Add opt-in support for OpenAPI 3.1 when targeting `net10.0`.
@martincostello
Copy link
Collaborator Author

@Poltuu Sorry that's currently broken due to #3368.

As a workaround you can get the NuGet packages from the CI build and either consume them from disk as a local package source, or upload them into your own custom NuGet feed.

See here for an example: martincostello/aspnetcore-openapi@d325e2a

Re-enable publishing to MyGet.
@martincostello
Copy link
Collaborator Author

MyGet publishing has been fixed - the latest version for .NET 10 preview 4 is 9.0.0-pr.3283.1426.

Apply some of the code-review suggestions. More to follow.
Workaround issue building the solution in Visual Studio.
bkoelman and others added 4 commits June 1, 2025 15:45
Fix incorrect handling of culture-sensitivity for number ranges.
Rename constant and move culture to variable.
- Use the correct culture to parse `[Range]`.
- Update snapshots.
Address code review comment.
Point to latest issue number.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file .NET Pull requests that update .NET code version-major A change suitable for release in a major version
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants