7.0.0 Preview 1

[commonsensesoftware]

This is the first preview release for ASP.NET Core with .NET 7.0 support. No additional work is planned, but there are some breaking changes that can be tried, tested, and discussed before promoting to the official release.

Features

ASP.NET Core

• Migrate from IProblemDetailsFactory to IProblemDetails
• Adding grouping support for MapGroup in Minimal APIs

Versioning Minimal APIs still requires a version set which collates configured API versions, but the new MapGroup support makes the setup more natural.

var builder = WebApplication.CreateBuilder( args );

builder.Services.AddApiVersioning();

var app = builder.Build();
var orders = app.MapGroup( "/api/order" ).WithApiVersionSet();

orders.MapGet( "/{id:int}", ( int id ) => new Order() { Id = id, Customer = "John Doe" } ).HasApiVersion( 1.0 );

ASP.NET Core with OData

• OData does not officially support .NET 7, but it is compatible
  • It is assumed that the eventual support will continue to be forward compatible or bump to 9.0
  • A breaking change in 9.0 could cause complication or require a major version bump for OData packages here

Breaking Changes

• As previously announced, .NET Core 3.1 has been dropped and is end of life in December 2022
• Minimal APIs implementation:
  • IVersionedEndpointConventionBuilder and VersionedEndpointConventionBuilder have been removed and are no longer necessary
  • DefaultApiVersionSetBuilderFactory now has a parameterless, default constructor
  • IVersionedEndpointConventionBuilder WithApiVersionSet(IEndpointConventionBuilder, ApiVersionSet) is now TBuilder WithApiVersionSet<TBuilder>(TBuilder, ApiVersionSet) where TBuilder : notnull, IEndpointConventionBuilder
• ProblemDetails implementation
  • IProblemDetailsFactory has been removed and is supplanted by the built-in IProblemDetailsService
  • The built-in IServiceCollection.AddProblemDetails() must be called to add ProblemDetails
    • This puts the control in your hands
    • Can result in a behavioral breaking change if you omit the setup

If you have additional input or feedback, please provide them in the discussion. This will be the one and only time to discuss it before the release becomes official.

---

This discussion was created from the release 7.0.0 Preview 1.

[Lonli-Lokli]

As far as I understand, MapGroup is not fully implemented with .NET7, see dotnet/aspnetcore#41433

[commonsensesoftware]

In terms of what ASP.NET Core itself supports, that may be true. I've found the current design to be pretty limiting. IEndpointConventionBuilder.Finally opened up a lot of doors for API Versioning, but it came in the 11th hour. I believe it was merged at or just before RC1, but it didn't make it in. That gave me little time to review or provide any feedback. That wasn't even part of the proposed design. I suspect after trying to implement some of the first party concepts, it was discovered just how limiting some things were.

For API Versioning, I do have something working in totality. I'm not convinced of the current approach. It would be more natural for API Versioning to create a group concept that subsequently piped into MapGroup. Fowler himself cautioned against doing that, so I've resisted. Some may remember the DefineApi from the 6.0 previews. I've provided some feedback on where things stand, but I'm not sure it will change anything. It might seem logical to start with MapApiVersion for a group, but there is a relationship of APIs across versions (hence starting with DefineApi as a logical entry point). I'm hesitant to go off script since there's no way to know what improvements or changes might come in .NET 8.0. Defining my own grouping API might result in a future breaking change if it's incompatible, even if that may be the right thing to do. I really strive to avoid breaking changes.

After spending quite a bit of time looking at the code, MapGroup is a minor shortcut to defining more succinct route templates and conventions for each Endpoint. Everything that you need to configure should still be possible, even if that might mean you have to configure stuff on endpoints individually. The documentation seems to suggest they expect people to know how and achieve that using extension methods to reduce the duplication.