Open stevendarby opened 4 weeks ago
P.S. I'd be happy to raise a PR if that would help its chances of getting into a 9.0.x release.
Workaround for swashbuckle, which works with the limited cases I have, but might not be generally applicable for everyone:
public class KeyedServicesFilter : IOperationFilter
{
public void Apply(OpenApiOperation operation, OperationFilterContext context)
{
if (context.ApiDescription.HttpMethod != HttpMethods.Get)
{
return;
}
var parameter = context.MethodInfo
.GetParameters()
.FirstOrDefault(p => p.CustomAttributes.Any(c => c.AttributeType.IsAssignableTo(typeof(FromKeyedServicesAttribute))));
if (parameter is not null)
{
operation.RequestBody = null;
if (context.SchemaRepository.TryLookupByType(parameter.ParameterType, out var schema))
{
context.SchemaRepository.Schemas.Remove(schema.Reference.Id);
}
}
}
}
Is there an existing issue for this?
Describe the bug
This is much like #50704 except for attributes derived from
FromKeyedServicesAttribute
. The fix for the previous issue only checked if the type was exactlyFromKeyedServicesAttribute
.Expected Behavior
I'm hoping this could be changed to use something like
IsAssignableTo/From
so that it covers derived attributes too.Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version
No response
Anything else?
Is there a workaround? e.g. some other "Ignore this" attribute I could apply to hide it?