Skip to content

Update Swashbuckle.AspNetCore to latest - #67136

Closed
Youssef1313 wants to merge 8 commits into
mainfrom
dev/ygerges/update-swashbuckle
Closed

Update Swashbuckle.AspNetCore to latest#67136
Youssef1313 wants to merge 8 commits into
mainfrom
dev/ygerges/update-swashbuckle

Conversation

@Youssef1313

@Youssef1313 Youssef1313 commented Jun 10, 2026

Copy link
Copy Markdown
Member

Until dotnet/aspnetcore#67134 is done, I think it should be safe to take this dependency update.

@Youssef1313
Youssef1313 requested review from a team and wtgodbe as code owners June 10, 2026 17:55
@Youssef1313
Youssef1313 requested review from Copilot and halter73 June 10, 2026 17:55
@github-actions github-actions Bot added the area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework label Jun 10, 2026
@Youssef1313

Copy link
Copy Markdown
Member Author

cc @martincostello

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

Updates the centrally-managed Swashbuckle.AspNetCore dependency version used across the repo, aligning the build’s external dependency set with a newer upstream release while the gRPC Swagger deprecation work (Issue #67134) is still pending.

Changes:

  • Bump Swashbuckle.AspNetCore from 6.6.2 to 10.2.1 via eng/Versions.props.

@wtgodbe wtgodbe left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

May need to kick off a run of https://dev.azure.com/dnceng/internal/_build?definitionId=931&_a=summary to get the package mirrored

@Youssef1313

Youssef1313 commented Jun 10, 2026

Copy link
Copy Markdown
Member Author

May need to kick off a run of https://dev.azure.com/dnceng/internal/_build?definitionId=931&_a=summary to get the package mirrored

Looks like it's already in dotnet-public since 2nd June.

Comment thread eng/Versions.props
<StackExchangeRedisVersion>2.7.27</StackExchangeRedisVersion>
<SystemReactiveLinqVersion>5.0.0</SystemReactiveLinqVersion>
<SwashbuckleAspNetCoreVersion>6.6.2</SwashbuckleAspNetCoreVersion>
<SwashbuckleAspNetCoreVersion>10.2.1</SwashbuckleAspNetCoreVersion>

@Youssef1313 Youssef1313 Jun 10, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

This is multiple major (breaking change) releases upgrade. If we are impacted by too much breaking changes, it might not be worth spending the time to fix those. Waiting for CI to tell.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

The breaking changes should all be related to the upgrade from Microsoft.OpenApi v1 ➡️ v2.

@Youssef1313

Copy link
Copy Markdown
Member Author

@copilot Try to address the build errors in Microsoft.AspNetCore.Grpc.Swagger.Tests

Co-authored-by: Youssef1313 <31348972+Youssef1313@users.noreply.github.com>

Copilot AI commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

@copilot Try to address the build errors in Microsoft.AspNetCore.Grpc.Swagger.Tests

Addressed in 6e4680f. The Grpc Swagger test project now uses the newer Microsoft.OpenApi namespace and no longer assumes swagger.Tags is indexable under the updated OpenAPI surface.

Copilot AI changed the title Update Swashbuckle.AspNetCore to latest Update Swashbuckle.AspNetCore and fix gRPC Swagger test compatibility Jun 11, 2026
@Youssef1313

Copy link
Copy Markdown
Member Author

@copilot There are additional errors:

D:\a\_work\1\s\src\Grpc\JsonTranscoding\test\Microsoft.AspNetCore.Grpc.Swagger.Tests\Binding\ResponseBodyTests.cs(6,25): error CS0234: The type or namespace name 'Any' does not exist in the namespace 'Microsoft.OpenApi' (are you missing an assembly reference?) [D:\a\_work\1\s\src\Grpc\JsonTranscoding\test\Microsoft.AspNetCore.Grpc.Swagger.Tests\Microsoft.AspNetCore.Grpc.Swagger.Tests.csproj]
D:\a\_work\1\s\src\Grpc\JsonTranscoding\test\Microsoft.AspNetCore.Grpc.Swagger.Tests\Infrastructure\OpenApiTestHelpers.cs(8,25): error CS0234: The type or namespace name 'Writers' does not exist in the namespace 'Microsoft.OpenApi' (are you missing an assembly reference?) [D:\a\_work\1\s\src\Grpc\JsonTranscoding\test\Microsoft.AspNetCore.Grpc.Swagger.Tests\Microsoft.AspNetCore.Grpc.Swagger.Tests.csproj]
D:\a\_work\1\s\src\Grpc\JsonTranscoding\test\Microsoft.AspNetCore.Grpc.Swagger.Tests\SchemaGeneratorIntegrationTests.cs(10,25): error CS0234: The type or namespace name 'Any' does not exist in the namespace 'Microsoft.OpenApi' (are you missing an assembly reference?) [D:\a\_work\1\s\src\Grpc\JsonTranscoding\test\Microsoft.AspNetCore.Grpc.Swagger.Tests\Microsoft.AspNetCore.Grpc.Swagger.Tests.csproj]
D:\a\_work\1\s\src\Grpc\JsonTranscoding\test\testassets\Sandbox\Startup.cs(4,25): error CS0234: The type or namespace name 'Models' does not exist in the namespace 'Microsoft.OpenApi' (are you missing an assembly reference?) [D:\a\_work\1\s\src\Grpc\JsonTranscoding\test\testassets\Sandbox\Sandbox.csproj]

Copilot AI and others added 4 commits June 11, 2026 09:45
Co-authored-by: Youssef1313 <31348972+Youssef1313@users.noreply.github.com>
Co-authored-by: Youssef1313 <31348972+Youssef1313@users.noreply.github.com>
Co-authored-by: Youssef1313 <31348972+Youssef1313@users.noreply.github.com>
Co-authored-by: Youssef1313 <31348972+Youssef1313@users.noreply.github.com>

Copilot AI commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

@copilot There are additional errors:

...

Addressed in d520f839. The remaining gRPC Swagger test breakages now use the updated Microsoft.OpenApi APIs (HttpMethod, IOpenApiSchema, JsonSchemaType, and root-namespace types), the Sandbox import is fixed, and source activate.sh && dotnet test src/Grpc/JsonTranscoding/test/Microsoft.AspNetCore.Grpc.Swagger.Tests/Microsoft.AspNetCore.Grpc.Swagger.Tests.csproj /p:BuildNodeJS=false /m:1 passes.

@Youssef1313 Youssef1313 changed the title Update Swashbuckle.AspNetCore and fix gRPC Swagger test compatibility Update Swashbuckle.AspNetCore to latest Jun 15, 2026
{
var code = responseNodes.Current!.GetAttribute("code", "");
if (!operation.Responses.TryGetValue(code, out var response))
if (!operation.Responses!.TryGetValue(code, out var response))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
if (!operation.Responses!.TryGetValue(code, out var response))
if (operation.Responses?.TryGetValue(code, out var response) == false)

can we handle the operation.Responses being null somehow more elegantly? maybe do null-assignment as well?

if we do not need it, maybe adding a comment helps explain this null-forgiving operator?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

The API is extremely confusing:

https://github.com/microsoft/OpenAPI.NET/blob/39d3cc23b819d09b0e990ec375fdb6261091f188/src/Microsoft.OpenApi/Models/OpenApiOperation.cs#L80

Esp when the documentation says "REQUIRED".

@baywet Could you clarify why Responses is annotated as nullable while the documentation says it's required?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

This was introduced in microsoft/OpenAPI.NET#1710

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@Youssef1313 I think the doc comment is an oversight... it's 9 years old!

The specification DOES NOT call this field out as required. Example of a required field in the spec

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

@baywet And besides that, is an empty dictionary here different from null?

Given that the property is already initialized to empty dictionary, what's the use case for setting it later to null? Why is that allowed?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm not sure why it's initialized to an empty dictionary, IMHO it shouldn't for multiple reasons:

  • deserialization: some documents might not have that property
  • confusing mix of implementation and API surface as you've outlined
  • increased memory consumption/pressure as we probably throw away that instance in a couple of scenarios like deserialization when responses are present, and collection initialization when creating a new document from the object model.

Again, the initial "initialization code" of the property is 9 years old!. I suspect this was done because at the time nullable reference types, which were introduced in C#8/2019, didn't exist.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

As for changing the value (not initializing it), it's been in here for a long time. I suspect it'd cause a bunch of regressions even though the API surface "says" you can have a null value in here.

As for changing the API surface to make it non-nullable, that'd be a breaking change, and wouldn't match the specification.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I don't think in this instance the specification makes a difference between null and empty for that collection. However it does for things like security requirements. Which is one reason why the library offers the distinction between null and empty collections as a general design principle.

@@ -100,7 +100,12 @@ private static void ApplyResponseTags(OpenApiOperation operation, XPathNodeItera
while (responseNodes.MoveNext())

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
while (responseNodes.MoveNext())
operation.Responses ??= [];
while (responseNodes.MoveNext())

Comment on lines +103 to +108
if (operation.Responses is null)
{
operation.Responses = [];
operation.Responses[code] = response = new OpenApiResponse();
}
else if (!operation.Responses.TryGetValue(code, out var response))

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
if (operation.Responses is null)
{
operation.Responses = [];
operation.Responses[code] = response = new OpenApiResponse();
}
else if (!operation.Responses.TryGetValue(code, out var response))
if (!operation.Responses.TryGetValue(code, out var response))

Wouldn't this perform better?

@Youssef1313

Copy link
Copy Markdown
Member Author

We will still prefer to simply tackle #67134 instead.

@Youssef1313
Youssef1313 deleted the dev/ygerges/update-swashbuckle branch June 15, 2026 21:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants