dotnet pack项目引用

我非常喜欢在几个程序集中分离功能，例如对数据提供程序的外观，数据提供程序的合同和数据提供程序实现本身......在我看来，它使得对单元测试一个功能块的各个组件，并且很容易在将来换出一件事情（就我的例子而言，它使数据提供者易于换出）。dotnet pack项目引用

如果我使用3个项目创建解决方案并使用项目引用，当我在入口程序集上构建dotnet时，所有引用都会复制到输出文件夹。当我使用dotnet打包组合项目来创建NuGET包时，NuGET包中只包含条目组合（不包括合同或数据提供者）。用于.NET Core dotnet-pack的documentation指出

项目到项目引用不打包在项目中。目前，如果您有项目到项目的依赖关系，则必须为每个项目包含一个包。

我的问题是 - 这是为什么？如果我想将我的代码分离为逻辑程序集，我不得不创建单独的NuGET程序包并引用它们，或者只是将所有代码整合到一个程序集中。有没有办法在NuGET包中包含项目引用？

我使用VS2017/.NET核心V1.1（的csproj，不xproj）

来源

2017-05-25 Jay

至于“为什么”，当文档说你“目前”必须做某件事时，通常意味着开发者没有时间去实现这个功能。 – svick

@svick哦，这是非常愤世嫉俗的（但可能是正确的！）我将离开这篇文章一段时间，以防止在不久的将来出现的1 assembly/NuGET包限制的某种方式。 – Jay

有点晚了，但让我尝试解释为什么我不希望有任何引用的项目程序集内被打包做入门包默认。

.NET核心基础架构设计为模块化，并基于软件包模型。基本上，.NET Core SDK和dotnet muxer（.NET核心引导程序和主机进程）首先使用软件包及其元数据工作，而不是直接处理它们的核心CLR的dll。因此，在最高级别的.NET Core中，程序包ID /版本是主要的，并且程序包内的dll名称/版本是次要的。

程序包本身（尽管是包含某些内容的档案）是一个抽象，由名称和版本标识。

假设我们有所需的dotnet pack行为，并且所有引用都打包到同一个入口包中。现在，如果我们有一个项目引用链，我们会得到一个包含所有dll的包。它可能适合我们的需求不够好，但它也违反了：

.NET核心的模块化理念（因为我们必须考虑的DLL文件，而不是抽象的包，这是唯一一个ID /版本 - 它会增加很多困惑和复杂性，因为我们还需要不具备一体化软件包，避免dll重复，在多个版本的情况下处理dll分辨率等的选项）
SRP（当某些引用的dll需要重建，我们需要更新整个软件包）。

关于这个问题，我认为，一个可行的办法来达到需要的是使用自定义.nuspec文件，你可以指定要打包

<PropertyGroup> 
    <NuspecFile>App.nuspec</NuspecFile> 
</PropertyGroup>

有了这个DLL时dotnet pack会产生该包相对于MyPackage.nuspec。此外，如果您有3个项目需要合同和实现，并且您不想添加3个软件包引用，那么您可以创建一个简单地将这3个作为依赖项并引用该单个软件包的软件包。

要包装起来，当前的Package-per-Project模型非常简单，对于自定义用例仍然很灵活。

来源

2017-12-25 08:53:18

dotnet pack项目引用

回答

相关问题