我开始将我的一些帮助程序和实用程序类收集到我的ASP.NET Core项目的可重用的库中（我倾向于这样做）。在这个过程中，我遇到了一些困难，经过与Twitter上的David Fowler的简短讨论后，我意识到自己从一开始就犯了一些非显而易见的错误。

在这篇快速文章中，我指出了我遇到的一些事情，并且在创建依赖于ASP.NET Core功能的类库时，您可能还需要注意。

不要参考ASP.NET核心元软件包

乍看之下，看起来确保您可以访问支持库中所有ASP.NET功能的最简单方法是引用Microsoft.AspNetCore.All带有所有ASP.NET Core依赖项的元数据包，就像默认的ASP.NET核心Web应用程序呢。

All包是适用于顶级应用程序的好方法，尤其是那些针对预安装的.NET Core运行时的应用程序。ASP.NET发布过程可以处理从哪里来装配程序，在大多数情况下，引用元程序包的引用，所有程序包只是指向预先安装的程序集。.NET然后在JIT时间整理出实际加载的程序集。

所以，当我创建我的类库时，我想，为什么不使用相同的包，并将其添加到我的classlib项目 - 毕竟大多数用例已经在顶级项目中已经有元包。

唉 - 大卫摇着我的数字手指，提醒我这不是一个好主意：

事后看来，这是非常有道理的。如果将类库的包粘贴到另一个项目中，它将继承依赖关系 - 即。整个ASP.NET堆栈。在大多数情况下，这可能不是一个问题，因为ALL元数据包可能已经在顶级Web项目中被引用。没有收获，没有丢失，对吧？

但是，在某些情况下，软件包可能会进入纯粹的本地安装应用程序，只使用它所需的依赖关系，而不是选择完整的ASP.NET堆栈指向预先安装的运行时。现在，消费者突然不得不依赖于所有这些程序集，无论我的lib提供了什么专门的功能。

更糟糕的是，如果其他类库想引用你的包，现在它也依赖于完整的ASP.NET堆栈。不酷。

简而言之，如果你正在构建一个内部库，你知道这个内部库会被一个使用完整元包的应用程序所使用，那么在你的类库中引用这个元包也许是可以的。

但是对于任何要在任何一种ASP.NET Core项目中使用的库，或者可能作为其他库的依赖库，仅仅引用实际需要的最小依赖关系更为明智。

ASP.NET核心类库和.NET标准

创建ASP.NET Core类库项目时出现了一个相关的问题。我通常创建目标.NET标准2.0的类库，因为它可能使库更加便携。使用ASP.NET核心可能不是一个关键的需求，因为它总是面向.NET核心应用程序（而不是.NET标准），但是谁知道未来会如何。

但是，当我引用ASP.NET Core元包时，类库项目自动强制我将目标定位到.NET Core 2.0。

图1 - 使用Microsoft.AspNetCore.All包迫使您使用NETCoreApp2.0目标

不仅如此，而且下拉列表实际上并没有提供在Visual Studio中更改目标的选项 - 它只给出了.NET Core的选项。这是怎么回事？

那么，ASP.NET Core元软件包实际上是负责改变目标，但我可以在.csproj文件中手动改变它：

<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netstandard2.0</TargetFramework> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="2.0.0" /> </ItemGroup></Project>

但是当我这样做，我得到这个错误：

图2 - 没有你的NETSTANDARD！

这里的问题再次Microsoft.AspNetCore.All 明确地针对.NET Core 2.0，以便它不被其他平台使用。

大卫还有一些：

基于大卫的建议，不使用ALL元包，我切换到特定的库，现在我可以在我的项目中的目标.NET标准2.0。

原因是.NET标准可以被其他平台使用，因此可能会引用我的包。如果元软件包在那里，我会最终包括元软件包中的所有这些程序集，说一个完整的.NET框架项目，这真的会吸引（我相信你已经诅咒了一些微软已经推出的.NET标准项目将一堆重复的组件放入Bin文件夹 - 同样的事情）。

坚持类库中的特定依赖关系

关键是，ASP.NET Core Meta包不是类库的好选择。因此，不是引用整个框架，而是仅引用应用程序实际需要的各个组件。是的 - 要找到合适的软件包还有更多的工作要做，更重要的是不要选择超级高级的软件包，而这些软件包最终还是会拉上世界的。

下，下，下层

此外，David建议确保您使用NuGet软件包的最低级别。例如，在最近的一篇文章中，我谈到了一个InputFormatter我搬到我的助手类库的类。这个库需要引用Microsoft.AspNetCore.Mvc.Core才能得到一个引用InputFormatter。然而，这个包是一个非常高级的包，它也包含大量的ASP.NET Core堆栈。David的建议是降低水平，考虑实施 IInputFormatter哪一个只需要Microsoft.AspNetCore.Mvc.Abstractions很低的水平，并且没有任何依赖性。

公平地说，这是一个艰难的召唤 - 我很快就发现，我遇到了其他依赖，在堆栈中居高不下。在这一点上，从零开始实施几个额外的接口，只是为了避免额外的参考。坦率地说 - 不值得，最后我确实需要使用这个Microsoft.AspNetCore.Mvc.Core软件包，但是你的要求可能会有所不同。你必须明智地选择你的战斗。

无论如何，我认为David的建议是正确的。从你所需要的开始，只需要添加特定的包。不要选择高级套餐作为您的第一个度假胜地 - 使用它作为最后的手段。

你需要什么？

这并不总是那么容易，因为发现事物的存在并不是自动的。ASP.NET Core和MVC分散在数十个软件包中。但是，SDK项目中的新NuGet工具至少会向您显示所有的NuGet包依赖关系，这通常可以帮助您明确导入哪些内容。

通过查看更高级别的依赖关系，您可以经常使用您实际需要的较低级别依赖关系来完成工作。

图3 - 您可以随时查看Package的依赖关系，并找出您需要的依赖关系。所有的软件包都可以在Microsoft.AspNetCore.AllWeb项目中查看。

一些包参考技巧

使用.NET API浏览器查找软件包引用

微软一直在大力投资创造良好的文档，并且一直在付出代价。如果您还没有在Microsoft Docs中检查出.NET Core或ASP.NET Core的常见主题，因为您认为这些文档是在“MSDN”上，那么您会感到震惊。

这些文档真的很好，可以向社区贡献。文档与单一文档系统的一致性也更加一致，这些文档系统以相同的格式覆盖了Microsoft Universe的大部分文档，使用相同的搜索工具和相同的贡献和编辑准则。认真地说 - 这是微软在MSDN以前地狱般的特殊地位所取得的巨大成就。

文档系统都是索引和可搜索的，这个新集成的一个非常好的功能是有一个非常有用的.NET API浏览器，现在您可以搜索类，名称空间，甚至成员名称。它使用一个自动完成查找的单个文本框，让您快速跳转到甚至发现API。

图4 - .NET API浏览器在发现哪些程序包/程序集组件所处的位置中是非常有用的

这很快，让你需要去。检查出来在：

.NET API浏览器

ASP.NET文档

文档提示：Nuget包和大会名称匹配

David提供的另一个有用的提示：ASP.NET Core和.NET Core Packages具有匹配的程序集和程序包名称。虽然文档只显示汇编名称，但在大多数情况下，它们应该匹配您可以在NuGet和.NET API浏览器上搜索的软件包名称。

发布，运行时和分发大小

在一天结束的时候使用.NET Core会增加一些额外的注意事项来处理依赖关系。与完整的框架.NET不同的是，.NET Core应用程序可以并行安装，并且可能没有可用的运行时间，这意味着每个依赖关系都必须复制到服务器上。

在.NET Core 1.x中，最初这是部署应用程序的唯一方式，这意味着您经常部署一个100兆的东西来运行一个小应用程序。

.NET Core 2.x（以及更高版本的1.x）带回了预先安装的运行时，并且尽管人们希望吹捧“自包含的应用程序”syndrom，但我认为大多数应用程序将使用预先安装的应用程序，安装运行时方式。与完整的框架不同，.NET Core支持并行运行时安装，这可以减轻与不同步运行时版本相关的全部框架问题中最糟糕的情况。

让我们永远记住，在运行时，.NET是足够聪明的知道什么程序集加载和实际代码与JIT编译。运行时未加载未引用的代码。因此，使用固定的运行时间，引用一些额外的包不会在运行时产生任何明显的差异。

尽管如此，本着纯代码的精神，精确而不是普遍的做法是一个好主意，所以做出合理的努力来保持依赖关系，特别是在类库中，这绝对是一个值得关注的问题。但是为了消除一个小的依赖性，可能是不值得的。

买者自负。

但是选择在那里让你决定。