Skip to content

Add Microsoft.AspNetCore.OpenApi package #41197

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 12 commits into from

Conversation

captainsafia
Copy link
Member

@captainsafia captainsafia commented Apr 14, 2022

Closes #40676.

<Reference Include="Microsoft.OpenApi" />
<Reference Include="Microsoft.AspNetCore.Http.Abstractions" />
<Reference Include="Microsoft.AspNetCore.Routing" />
<Reference Include="Microsoft.AspNetCore.Mvc.Core" />
Copy link
Member

Choose a reason for hiding this comment

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

Organization question: Why put this under /Http/ when it depends on higher level components like MVC?

Copy link
Contributor

@dougbu dougbu left a comment

Choose a reason for hiding this comment

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

This looks fine to me. I agree w/ @Tratcher's point about placing the new projects under src/Mvc or somewhere nearby that already uses MVC packages.

{
return httpMethod switch
{
"GET" => OperationType.Get,
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Don't we have constants or static readonly properties somewhere for all of these strings❔

<GenerateDocumentationFile>true</GenerateDocumentationFile>
<PackageTags>aspnetcore;openapi</PackageTags>
<Nullable>enable</Nullable>
<Trimmable>true</Trimmable>
Copy link
Contributor

Choose a reason for hiding this comment

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

Has trim-ability been tested❔

<PropertyGroup>
<TargetFramework>$(DefaultNetCoreTargetFramework)</TargetFramework>
<GenerateDocumentationFile>true</GenerateDocumentationFile>
<PackageTags>aspnetcore;openapi</PackageTags>
Copy link
Contributor

Choose a reason for hiding this comment

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

The package deserves a <Description>...</Description>. Otherwise people will need to guess its point from the package name and these tags. Suggest also adding more information to the commit and maybe the PR descriptions.

var pattern = routeEndpointBuilder.RoutePattern;
var metadata = new EndpointMetadataCollection(routeEndpointBuilder.Metadata);
var methodInfo = metadata.OfType<MethodInfo>().SingleOrDefault();
var serviceProvider = routeEndpointBuilder.Metadata.OfType<IServiceProvider>().SingleOrDefault();
Copy link
Member

Choose a reason for hiding this comment

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

This is kinda jank. The IServiceProvider shouldn't be metadata. I guess there's no other way to get the IServiceProvider? Can we defer the need for it later?

Copy link
Member Author

Choose a reason for hiding this comment

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

I guess there's no other way to get the IServiceProvider?

Not that I can reason about.

Can we defer the need for it later?

There's some alternatives. We mostly need DI to access the services we need to determine what parameters are what. We can punt on checking those parameters and make a parameter-less constructor for OpenApiGenerator that we instantiate directly here without relying on DI.

But I think we have to solve that problem eventually...

Comment on lines 513 to 520
// Add the ServiceProvider to metadata so that it can be resolved
// by extension methods that need accesses to the same services that
// are registered by the target endpoint.
if (endpoints.ServiceProvider is not null)
{
builder.Metadata.Add(endpoints.ServiceProvider);
}

Copy link
Member

Choose a reason for hiding this comment

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

@Pilchie Pilchie added the old-area-web-frameworks-do-not-use *DEPRECATED* This label is deprecated in favor of the area-mvc and area-minimal labels label Apr 15, 2022
@dougbu
Copy link
Contributor

dougbu commented Apr 18, 2022

Did you mean to close this @captainsafia

@captainsafia
Copy link
Member Author

Did you mean to close this @captainsafia

Yep, I ended up cleaning the commit history and opening a new PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
old-area-web-frameworks-do-not-use *DEPRECATED* This label is deprecated in favor of the area-mvc and area-minimal labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Introduce Microsoft.AspNetCore.OpenApi package
5 participants