Yes, this also happened to us for a trimmed (copyused) application, whereas in .NET 6 this was not an issue.

We have been paying attention to this issue for some time.
Is there any progress?

I think this is an easy problem to solve.
Why hasn't it been fixed?

.NET 8 preview 3 has added a Native AOT template for Web APIs (dotnet new api -aot). Would be nice if Swashbuckle worked for these templates.

See: https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-8-preview-3/

.NET 8 is nearing release. Wondering if this was considered for an upcoming release

Seems that this is related to dotnet/runtime#92345, and the workaround is adding <JsonSerializerIsReflectionEnabledByDefault>true</JsonSerializerIsReflectionEnabledByDefault>
to the publish project. However, that enables it everything, not only Swashbuckle.

It is recommended to switch source-generated context, however it would be enough to explicitly enable reflection-based serialization - https://learn.microsoft.com/en-us/dotnet/core/compatibility/serialization/7.0/reflection-fallback#use-a-custom-contract-resolver. .NET 8 RC1 has already been released, is there any plan to not break builds with trimming enabled?

I think the JsonSerializerIsReflectionEnabledByDefault is just a workaround for people whose application no longer compiles / starts whe moving from .NET 7 to .NET 8.

The reflection based resolver might still randomly fail when trimming is enabled and I believe it's guaranteed to fail when using Native AOT. So you just end up with a Swashbuckle endpoint that might or might not work after every change in your code or update in the .NET compiler.

I've switched to building an OpenAPI spec file using Swashbackle and not using Swashbuckle in the Release build configuration. See: https://medium.com/@mimme/generate-open-api-specification-for-asp-net-core-projects-on-build-c5789d435ffc (the only thing I did different from the medium article was using a seperate OpenApiSpec build configuration as to not make the Debug build dependent on swagger CLI tool)

@quality-leftovers And how do you handle the Swagger UI? Currently the exception happens in the RespondWithIndexHtml method, so I don't see how using the CLI to generate the spec fixes this issue

Any updates on this topic? .NET 8 releases next week and we would love to use swagger UI.

Disclaimer: I am NOT a contributor to this repo
but I can see the PR is ready to be merged but it is not merged yet,
I hope that it will be merged ASAP
Thank you all

Any updates on this ?

I would also love a fix for this.

Please just add the code generated serializers for the net8 publication of the package to make sure it is trimming and AOT compatible.

If it's a dangerous change, can we maybe have something like "6.6.0-beta1" nuget where it's included?

I get the impression the repo is currently not being maintained.

@VMelnalksnis Maybe I was uncleear. I'm not using swagger UI in the release version anymore.

I'm just generating an OpenAPI yaml now.

In .csproj:

<Configurations>Debug;Release;OpenApiSpec</Configurations>

  <!-- Requires dotnet tool Swashbuckle.AspNetCore.Cli -->
  <Target Name="OpenAPI" AfterTargets="Build" Condition="$(Configuration)=='OpenApiSpec'">
    <Exec Command="dotnet swagger tofile --output ../ConnectionCenterApi.OpenAPI.yaml --yaml $(OutputPath)$(AssemblyName).dll v1" WorkingDirectory="$(ProjectDir)" />
  </Target>

and in the Program.cs something along the lines of

#if DEBUG || OPENAPISPEC
    builder.Services.AddEndpointsApiExplorer();
    builder.Services.AddSwaggerGen();
#endif

#if DEBUG || OPENAPISPEC
       app.UseSwagger()
       .UseSwaggerUI();
#endif

Can you guys test if DotSwashbuckle solves the issue? Its for .NET 8+ only

Any updates? this is a blocker btw

We can look to address this once #2792 is implemented.