-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
base: master
Are you sure you want to change the base?
Support .NET 10 #3283
Conversation
test/WebSites/WebApi/WebApi.csproj
Outdated
<!-- 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> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cherry-pick refactoring from #3283 to make multi-targeting easier for ASP.NET Core 10 and Microsoft.OpenApi v2.
86395ee
to
eaa77f6
Compare
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. |
Moved some of the changes into #3286 so we can prepare users for the change and also then change this PR to remove |
@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? |
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 ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found. 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
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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. |
Also, |
@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
You've probably already gleened this from the implementation, but 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. |
Thanks for the pointers @captainsafia - I'll use those for reference once I start reacting to 10.0.0-preview.2 changes 🙇 |
- 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`.
ef09eab
to
18458de
Compare
@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.
MyGet publishing has been fixed - the latest version for .NET 10 preview 4 is |
src/Swashbuckle.AspNetCore.SwaggerGen/SchemaGenerator/OpenApiSchemaExtensions.cs
Outdated
Show resolved
Hide resolved
Apply some of the code-review suggestions. More to follow.
Workaround issue building the solution in Visual Studio.
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.
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.#3285TODO
Before merge:
VersionPrefix
is correct for the next major version at the time of mergeUseOpenApiDocument.SerializeAs()
method[Obsolete]
that are appropriateIOpenApiSchema
toOpenApiSchema
)Description
properties where appropriate (see [Feature request]: Support for OpenAPI Description in [ProducesResponseType], [Produces], and [ProducesDefaultResponseType] Attributes #3099)Prerelease builds from this PR can be consumed from MyGet: