blocks|key|832199|text|.AddEndpointsApiExplorer()是为了支持最小Api's而创建的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|832200|通过谷歌搜索文档显示了许多页面，其中包括对.AddEndpointsApiExplorer()的调用。但是，没有提到为什么需要它，也没有提到从v5项目迁移时是否需要它。文档显然缺乏。|832201|从源代码&+怪罪反向工作，我找到了相关项目。因此，答案似乎与对最小Api's的支持有关。|832202|我相信一些新的服务是为了从这些新的最小api中提取返回类型信息而创建的，当使用没有MVC的端点路由时，这种方式可能适用于更一般的方式。|832203|如果您正在使用MVC，也许是通过.AddControllers()，则会为您调用.AddApiExplorer()。提供swagger所依赖的服务来描述控制器操作。如果这是您所需要的，那么这个新的api调用似乎并不是必需的。|832204|而使用最小api的昂首阔步文档包括对.AddEndpointsApiExplorer()的调用。即便如此，也不能确切地解释为什么需要这样做。|832205|为什么.AddEndpointsApiExplorer()会存在？为什么新特性被排除在.AddApiExplorer()之外？为什么在v6的其他文档中忽略了这个方法重命名？|832206|也许我们应该在https://github.com/dotnet/aspnetcore/或https://github.com/dotnet/AspNetCore.Docs/上创建一个问题来要求澄清，这样其他人就不必问这些问题了。|832207|entityMap|0|LINK|mutability|MUTABLE|url|https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-6.0|1|https://github.com/dotnet/aspnetcore/blame/main/src/Mvc/Mvc.ApiExplorer/src/DependencyInjection/EndpointMethodInfoApiExplorerServiceCollectionExtensions.cs|2|https://github.com/dotnet/aspnetcore/projects/18|3|4|https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-6.0#openapi|5|https://github.com/dotnet/aspnetcore/|6|https://github.com/dotnet/AspNetCore.Docs/^0|0|Q|V|7|0|0|L|Q|0|6|2|1|H|4|2|V|7|3|0|0|G|H|14|H|0|I|Q|9|4|4|0|3|Q|17|H|0|7|11|5|19|16|6|0^^$0|@$1|2|3|4|5|6|7|1C|8|@$9|1D|A|1E|B|C]]|D|@$9|1F|A|1G|1|1H]]|E|$]]|$1|F|3|G|5|6|7|1I|8|@$9|1J|A|1K|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1L|8|@]|D|@$9|1M|A|1N|1|1O]|$9|1P|A|1Q|1|1R]|$9|1S|A|1T|1|1U]]|E|$]]|$1|J|3|K|5|6|7|1V|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|1W|8|@$9|1X|A|1Y|B|C]|$9|1Z|A|20|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|21|8|@$9|22|A|23|B|C]]|D|@$9|24|A|25|1|26]]|E|$]]|$1|P|3|Q|5|6|7|27|8|@$9|28|A|29|B|C]|$9|2A|A|2B|B|C]]|D|@]|E|$]]|$1|R|3|S|5|6|7|2C|8|@]|D|@$9|2D|A|2E|1|2F]|$9|2G|A|2H|1|2I]]|E|$]]|$1|T|3|-4|5|6|7|2J|8|@]|D|@]|E|$]]]|U|$V|$5|W|X|Y|E|$Z|10]]|11|$5|W|X|Y|E|$Z|12]]|13|$5|W|X|Y|E|$Z|14]]|15|$5|W|X|Y|E|$Z|10]]|16|$5|W|X|Y|E|$Z|17]]|18|$5|W|X|Y|E|$Z|19]]|1A|$5|W|X|Y|E|$Z|1B]]]]

TLDR; <code>.AddEndpointsApiExplorer()</code> was created to support <a href="https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-6.0" rel="noreferrer">Minimal Api's</a>.
Searching the doc's via google shows a number of pages that include a call to <code>.AddEndpointsApiExplorer()</code>. But no mention of why you need it, or if it is required when migrating from a v5 project. The documentation is definitely lacking.
Working backwards from the source code &amp; <a href="https://github.com/dotnet/aspnetcore/blame/main/src/Mvc/Mvc.ApiExplorer/src/DependencyInjection/EndpointMethodInfoApiExplorerServiceCollectionExtensions.cs" rel="noreferrer">git blame</a>, I found the <a href="https://github.com/dotnet/aspnetcore/projects/18" rel="noreferrer">related project</a>. So the answer appears to be related to support for <a href="https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-6.0" rel="noreferrer">Minimal Api's</a>.
I believe some new services were created to extract return type information from these new minimal api's, in a way that might apply in a more general way when using Endpoint Routing without MVC.
If you are using MVC, perhaps via <code>.AddControllers()</code>, <code>.AddApiExplorer()</code> would be called for you. Providing the services that swagger depends on for describing controller actions. If that's all you need, then this new api call doesn't seem to be required.
While the documentation for using <a href="https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-6.0#openapi" rel="noreferrer">swagger</a> with minimal api's includes a call to <code>.AddEndpointsApiExplorer()</code>. Even that doesn't explain exactly why it is required.
Why does <code>.AddEndpointsApiExplorer()</code> exist at all? Why were the new features excluded from <code>.AddApiExplorer()</code>? Why was this method rename left out of other documentation for v6?
Perhaps we should create an issue on <a href="https://github.com/dotnet/aspnetcore/" rel="noreferrer">https://github.com/dotnet/aspnetcore/</a> or <a href="https://github.com/dotnet/AspNetCore.Docs/" rel="noreferrer">https://github.com/dotnet/AspNetCore.Docs/</a> to ask for clarification so that others don't have to ask these questions.

blocks|key|1663207|text|AddEndpointsApiExplorer是最低限度的API，而AddApiExplorer至少需要MVC核心。对于API项目，AddControllers代表您调用AddApiExplorer。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1663208|但是为什么所有的东西都与AddEndpointsApiExplorer**?**+一起工作呢？|BOLD|1663209|随着端点路由的引入，路由系统中的一切都归结为Endpoint。ASP.NET核心使用应用程序模型，即ApplicationModel、ControllerModel和ActionModel来创建Endpoint实例并将它们注册到路由系统中。但是，最小API使用构建器直接创建和注册单个Endpoint实例。|1663210|默认的API实现提供了一个IApiDescriptionProvider，它从应用程序模型构建ApiDescription实例。最小的API没有应用程序模型，因此没有什么可用于构建ApiDescription实例的。are提供了这些描述，这些描述通常由诸如OpenAPI生成器之类的工具使用。如果没有任何描述，就不会支持最小的API和OpenAPI；这将是糟糕的(或者至少不被开发人员所接受)。为了解决这个问题，ASP.NET核心团队创建了第二个只考虑Endpoint的IApiDescriptionProvider。|1663211|如果一切都是Endpoint**，，为什么不合并实现？**|1663212|这个答案有两部分。首先，更改原始的IApiDescriptionProvider实现将引入一个公共的、破坏性的更改。至少需要新的构造函数参数。因为这是一个主要的版本碰撞，这种方法并没有脱离桌面，但事实证明它是不相关的。更大的问题是，最初的IApiDescriptionProvider实现和AddApiExplorer生活在和依赖于MVC核心。最小的API只需要路由抽象。如果不添加不必要的耦合，就无法将两者合并。为了解决这个问题，添加了AddEndpointsApiExplorer，它添加了一个只需要基于路由系统的基本Endpoint定义的IApiDescriptionProvider实现的实现。|1663213|如果AddEndpointsApiExplorer存在并且我称之为它，我还需要AddApiExplorer吗？也许吧。在最小API+Endpoint实例上公开和可用的元数据比应用程序模型轻得多；毕竟，它们是最小的。在幕后，IApiDescriptionGroupCollectionProvider实现接受一系列IApiDescriptionProvider实例。如果调用了AddEndpointsApiExplorer和AddApiExplorer，那么两个提供程序都将执行。如果只调用AddEndpointsApiExplorer，它将与常规的“ol控制器”一起工作，但是描述的信息保真度可能比您习惯的要小。如果您只创作最小的API，那么如果您想要API支持，就需要AddEndpointsApiExplorer。|1663214|在.NET+7.0中，这两种方法之间的保真度提高得更多。在未来的某个版本中，我们可能会看到这些方法结合在一起。|blockquote|1663215|entityMap^0|0|N|Y|E|1U|E|2D|E|0|C|P|15|6|C|N|0|0|49|M|8|1E|G|1V|F|2B|B|2P|8|3Y|8|0|0|77|D|N|1B|E|2I|E|6A|8|6J|N|0|0|T|6|8|0|0|8D|H|N|3B|N|41|E|63|N|79|8|7K|N|0|0|9Z|2|N|13|E|1U|8|33|12|4C|N|57|N|5V|E|6S|N|9B|N|0|0|1J|0^^$0|@$1|2|3|4|5|6|7|X|8|@$9|Y|A|Z|B|C]|$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|16|8|@$9|17|A|18|B|H]|$9|19|A|1A|B|H]|$9|1B|A|1C|B|C]]|D|@]|E|$]]|$1|I|3|J|5|6|7|1D|8|@$9|1E|A|1F|B|H]|$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]|$9|1K|A|1L|B|C]|$9|1M|A|1N|B|C]|$9|1O|A|1P|B|C]|$9|1Q|A|1R|B|C]]|D|@]|E|$]]|$1|K|3|L|5|6|7|1S|8|@$9|1T|A|1U|B|H]|$9|1V|A|1W|B|C]|$9|1X|A|1Y|B|C]|$9|1Z|A|20|B|C]|$9|21|A|22|B|C]|$9|23|A|24|B|C]]|D|@]|E|$]]|$1|M|3|N|5|6|7|25|8|@$9|26|A|27|B|H]|$9|28|A|29|B|C]]|D|@]|E|$]]|$1|O|3|P|5|6|7|2A|8|@$9|2B|A|2C|B|H]|$9|2D|A|2E|B|C]|$9|2F|A|2G|B|C]|$9|2H|A|2I|B|C]|$9|2J|A|2K|B|C]|$9|2L|A|2M|B|C]|$9|2N|A|2O|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|6|7|2P|8|@$9|2Q|A|2R|B|H]|$9|2S|A|2T|B|C]|$9|2U|A|2V|B|C]|$9|2W|A|2X|B|C]|$9|2Y|A|2Z|B|C]|$9|30|A|31|B|C]|$9|32|A|33|B|C]|$9|34|A|35|B|C]|$9|36|A|37|B|C]|$9|38|A|39|B|C]]|D|@]|E|$]]|$1|S|3|T|5|U|7|3A|8|@$9|3B|A|3C|B|H]]|D|@]|E|$]]|$1|V|3|-4|5|6|7|3D|8|@]|D|@]|E|$]]]|W|$]]

<code>AddEndpointsApiExplorer</code> is for Minimal APIs whereas <code>AddApiExplorer</code> requires, at least, MVC Core. For API projects, <code>AddControllers</code> calls <code>AddApiExplorer</code> on your behalf.
But Why Does Everything Still Work With <code>AddEndpointsApiExplorer</code>?
With the introduction of Endpoint Routing, everything in the routing system boils down to an <code>Endpoint</code>. ASP.NET Core uses the Application Model, namely <code>ApplicationModel</code>, <code>ControllerModel</code>, and <code>ActionModel</code>, to create <code>Endpoint</code> instances and register them with the routing system. Minimal APIs, however, use a builder to directly create and register individual <code>Endpoint</code> instances.
The default API Explorer implementation provides a <code>IApiDescriptionProvider</code> that builds <code>ApiDescription</code> instances from the Application Model. Minimal APIs do not have an Application Model so there is nothing to build <code>ApiDescription</code> instances from. The API Explorer provides these descriptions, which are commonly used by tools such as OpenAPI generators. Without any descriptions, there would be no support for Minimal APIs and OpenAPI; that would be bad (or, at least, certainly not accepted by developers). To address that, the ASP.NET Core team created a second <code>IApiDescriptionProvider</code> that only considers <code>Endpoint</code>.
If Everything is an <code>Endpoint</code>, Why Not Merge Implementations?
There's two parts to this answer. First, changing the original <code>IApiDescriptionProvider</code> implementation would introduce a public, breaking change. At a minimum, new constructor arguments would be required. Since it was a major version bump, this approach wasn't off the table, but it turns out to be irrelevant. The bigger issue is that the original <code>IApiDescriptionProvider</code> implementation and <code>AddApiExplorer</code> live in and depend on MVC Core. Minimal APIs only require the routing abstractions. There is no way to merge the two without adding unnecessary coupling. To address this problem, <code>AddEndpointsApiExplorer</code> was added which adds an implementation that only requires an <code>IApiDescriptionProvider</code> implementation based on bare bones <code>Endpoint</code> definitions from the routing system.
If <code>AddEndpointsApiExplorer</code> exists and I call it, do I even need <code>AddApiExplorer</code> anymore? Maybe. The metadata exposed and available on Minimal API <code>Endpoint</code> instances is much lighter than the Application Model; after all, they are minimal. Behind the scenes, a <code>IApiDescriptionGroupCollectionProvider</code> implementation takes a sequence of <code>IApiDescriptionProvider</code> instances. If <code>AddEndpointsApiExplorer</code> and <code>AddApiExplorer</code> are called, then both providers will execute. If only <code>AddEndpointsApiExplorer</code> is called, it will work with regular 'ol controllers, but the descriptions' information fidelity might be less than what you are accustomed to. If you are only authoring Minimal APIs, then <code>AddEndpointsApiExplorer</code> is required if you want API Explorer support.
<blockquote>
The fidelity between the two methods is improving even more in .NET 7.0. In some future release, it's possible we might see these approaches coalesce into one.
</blockquote>

blocks|key|825718|text|TL;DR|type|unstyled|depth|inlineStyleRanges|entityRanges|data|825719|只有在使用V6的“最小API”时才使用AddEndpointsApiExplorer，这些API如下所示：|offset|length|style|CODE|825720|app.MapGet("/",+()+=>+"Hello+World!");|code-block|syntax|javascript|825721|entityMap^0|0|J|N|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@$D|Q|E|R|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|S|8|@]|9|@]|A|$K|L]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

TL;DR
Only use <code>AddEndpointsApiExplorer</code> if you use v6's &quot;minimal APIs&quot;, which look like this:
<pre class="lang-cs prettyprint-override"><code>app.MapGet(&quot;/&quot;, () =&gt; &quot;Hello World!&quot;);
</code></pre>

I'm upgrading an ASP.NET Core API project from v5 to v6.
Service config in <a href="https://learn.microsoft.com/en-us/aspnet/core/tutorials/getting-started-with-swashbuckle?view=aspnetcore-5.0&amp;tabs=netcore-cli#add-and-configure-swagger-middleware-1" rel="noreferrer">v5</a>:
<pre class="lang-cs prettyprint-override"><code>services.AddSwaggerGen();
</code></pre>
Service config in <a href="https://learn.microsoft.com/en-us/aspnet/core/tutorials/getting-started-with-swashbuckle?view=aspnetcore-6.0&amp;tabs=netcore-cli#add-and-configure-swagger-middleware" rel="noreferrer">v6</a>:
<pre class="lang-cs prettyprint-override"><code>builder.Services.AddEndpointsApiExplorer(); // what is this?
builder.Services.AddSwaggerGen();
</code></pre>
What is <code>AddEndpointsApiExplorer</code>? Everything works as expected whether I add it or not.
I use the &quot;ASP.NET API Versioning&quot; <a href="https://github.com/dotnet/aspnet-api-versioning" rel="noreferrer">library</a>. Are they related? If so, must I use both, just the library, or is the library unnecessary now?

What is AddEndpointsApiExplorer in ASP.NET Core 6

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

我正在将ASP.NET Core项目从v5升级到v6。中的服务配置services.AddSwaggerGen();中的服务配置builder.Services.AddEndpointsApiExplorer();    // what is this?builder.Services.AddSwaggerGen();...

问AddEndpointsApiExplorer在ASP.NET核心6中是什么？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问AddEndpointsApiExplorer在ASP.NET核心6中是什么？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问AddEndpointsApiExplorer在ASP.NET核心6中是什么？
EN