Repository navigation
Deprecate Microsoft.AspNetCore.Grpc.Swagger #67134
Description
Microsoft.AspNetCore.Grpc.Swagger has remained an experimental package with limited usage and no recent investment. It provides Swagger/OpenAPI support for gRPC, but:
- It depends indirectly on Swashbuckle, rather than integrating with
Microsoft.OpenApi - The ecosystem has standardized on Swashbuckle.AspNetCore and newer OpenAPI tooling
- It introduces additional dependency and maintenance complexity
- Low usage relative to maintenance cost
The proposal is to deprecate the Microsoft.AspNetCore.Grpc.Swagger package.
Recommended alternatives:
- Use Swashbuckle.AspNetCore directly for OpenAPI/Swagger scenarios
- Use gRPC JSON transcoding (
Microsoft.AspNetCore.Grpc.JsonTranscoding) for HTTP API exposure
Reacted by Martin Costello
Activity
halter73 commentedon Jun 10, 2026
I think we can stop publishing this immediately, since we've never released a stable version. We'll want to make sure to close out any related issues like #65228
github-actions commentedon Jun 10, 2026
Triage Summary
Area:
area-grpc(request targets theMicrosoft.AspNetCore.Grpc.Swaggerpackage, which lives undersrc/Grpc/)Type:
Task(deprecating an existing package is maintenance/operational work)Potential Duplicates
adam8797 commentedon Jul 14, 2026
I've had #66861 open for a few months now, which is a proposal for an improvement to this package.
If you want to deprecate, that seems reasonable especially with OpenAPI replacing Swashbuckle in general use, but I think this package fills a hole that isn't available directly without it.
For users that publish a gRPC API with JSON Transcoding enabled, how are they to create an OpenAPI document for the transcoded routes? The recommended alternatives do not cover this use. Please correct me if I'm wrong, it would save me a lot of trouble if there was an alternative supported solution.
atrokhovsergey commentedon Jul 14, 2026
There are no alternatives for exposing OpenAPI documentation for transcoded gRPC APIs without this package. I think users need it.
danroth27 commentedon Jul 22, 2026
We recognize that Microsoft.AspNetCore.Grpc.Swagger provides useful functionality and addresses a real scenario for some developers. However, the ASP.NET Core team has to make ongoing scoping and prioritization decisions based on the resources available to us, and we've chosen not to invest further in turning this experimental package into a supported offering. We think it's important to be transparent about those decisions so developers can make informed technology choices. Clear support boundaries also create space for the broader .NET ecosystem to innovate and invest in areas where Microsoft is not planning to provide a supported solution. Deprecating this package is not a statement that the scenario isn't important, but rather a reflection of where we're focusing our limited engineering resources while continuing to support a strong platform for the community to build on. For those who care deeply about this scenario, we encourage you to build on the .NET platform and help drive the ecosystem forward with solutions that meet these needs.
adam8797 commentedon Jul 22, 2026
Thanks @danroth27, it makes complete sense to be honest. Swagger is deprecated and it would take effort to port to OpenAPI for not many users. The math seems pretty clear to me there.
The thing I take issue with is largely around communication:
At any point in the past seven months literally any maintainer could have left a “Hey actually we’re considering dropping support for this, you should explore other options” and honestly that’s totally fine. It’s your right to do that! I just need to know so I can make decisions around what I’m building.
I’ve taken the liberty of “forking” the removed code only and begun the process of repackaging it into something standalone. That I’ll publish on NuGet for the few of us that need something like this. That’s the beauty of open source, and I’m thankful you guys work out in the open like this.
I may even get around to supporting Microsoft.OpenAPI directly! I’ll post back here when that’s ready so others can find the package (so apologies in advance for that ping).
I’m a huge fan of .NET and this whole ecosystem, I taught myself VB and C# when I was a kid, so I love seeing you guys succeed, but I’ve found it incredibly frustrating to get non-community support or communication.
danroth27 commentedon Jul 24, 2026
@adam8797 I do apologize for lack of communication and engagement on your issues and proposals. We need to do better at being clear and responsive to our contributors.
I'm thrilled to hear that you're planning to fork and build on the existing code! Enabling our community to know where they can best contribute to the ecosystem is exactly why clear communication on our end is so important.
Rand-Random commentedon Aug 4, 2026
@JamesNK @danroth27
Please update this documentation:
https://learn.microsoft.com/en-us/aspnet/core/grpc/json-transcoding-openapi?view=aspnetcore-10.0
which explains to use the deprecated packages and its one of the first search results about this topic.
adam8797 commentedon Aug 10, 2026
As promised, I've published https://github.com/adam8797/Community.Grpc.OpenApi after Microsoft dropped the package.
It includes the design I proposed in #66861, but if you do not want that feature the base version 10.0.0 build is a verbatim copy of what was removed, with bare modifications needed to make it build outside the aspnetcore repo.
PRs welcome to keep it up to date.
brinehart commentedon Sep 23, 2026
@danroth27
Does this deprecation point to a larger slowdown or abandonment of gRPC in .NET?
This unexpected deprecation is a major problem for our team. We bought the gRPC with JSON transcoding vision wholeheartedly and I really believed this was a perfect way to build robust enterprise ready APIs. Our team has spent a ton of investment and time building out a lot of gRPC services that all utilize JSON Transcoding and expose swagger specs.
We put much effort into making the process of building many gRPC APIs with HTTP endpoints exposed via JSON Transcoding within our organization seemless. Without this piece of the puzzle we don't have a good way to generate Swagger or OpenAPI specs to be consumed by our partners for integration with our business. Is there a Microsoft.OpenApi package in development to replace this?
I totally get the abandonment of Swagger in the .NET ecosystem due to the well publicized issues and see how this decision fits that larger goal. But, without a viable OpenAPI alternative this leaves us in quite a lurch.
Does anyone have any viable alternatives for generating OpenApi specs (preferably v3 - 3.1) that have worked for you?