Do not consider abstract classes in configuration options

[gsteenpa]

We use an abstract base class to share some configuration options. The resolver is picking up that abstract class and thowing an error on the SingleOrDefault.

This is the exception stack:

Sequence contains more than one matching element

   at System.Linq.ThrowHelper.ThrowMoreThanOneMatchException()
   at System.Linq.Enumerable.TryGetSingle[TSource](IEnumerable`1 source, Func`2 predicate, Boolean& found)
   at System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
   at Microsoft.Azure.WebJobs.Extensions.OpenApi.Core.Resolvers.OpenApiConfigurationResolver.Resolve(Assembly assembly)
   at Microsoft.Azure.WebJobs.Extensions.OpenApi.OpenApiHttpTriggerContext.get_OpenApiConfigurationOptions()
   at Microsoft.Azure.WebJobs.Extensions.OpenApi.OpenApiTriggerFunctionProvider.RenderSwaggerUI(HttpRequest req, ExecutionContext ctx, ILogger log)

[justinyoo]

@gsteenpa Thanks for the PR! However, I wonder whether this really needs or not because there's no abstract class in the code implementing IOpenApiConfigurationOptions, anyway. Would you mind providing a use case for this?

[gsteenpa]

@gsteenpa Thanks for the PR! However, I wonder whether this really needs or not because there's no abstract class in the code implementing IOpenApiConfigurationOptions, anyway. Would you mind providing a use case for this?

Hi - We have an abstract base in our usage of the library so that we can share some settings (like setting a standard copyright with a dynamic year, forcing a specific openapi spec version, and ensuring a standard api title/description) across various apis. Each api then inherits from that base class in its implementation (the "concrete" class) to set api specific information.

[justinyoo]

Oh, I see. Then, it would make senses.

[justinyoo]

Would you please add test cases to validate your change?

[justinyoo]

Thanks for your contribution! It LGTM