背景：我有两个程序集，称为“A”和“B”。 “A”引用了“B”。“A”还引用了一些其他 dll（Microsoft.Enterprise Library.Data 和 Microsoft Enterprise Library.Common ），我认为这些 dll 应该打包在 nupkg 中。
我相信我的 nupkg 包应该包含来自“A”、“B”和两个“Microsoft Enterprise”程序集的程序集输出，这样当有人安装我的程序包时，它将为他们提供对程序集“A”和其他三个程序集的直接引用程序集将可用（但不直接引用，以便其应用程序能够运行。打包非引用 dll 的正确方法是什么？
尝试#1：将所有必需的 dll 打包到 \net35 文件夹中根据有关“参考”的 NuGet 文档 http://docs.nuget.org/docs/reference/nuspec-reference#Specifying_Dependencies_in_version_2.0_and_aboveelement “如果省略此元素，则应用通常的行为，即引用 lib 文件夹中的每个程序集。”
因此，我假设通过使用此元素，它将仅包含指定为引用的程序集。如果我也使用“文件”元素，情况似乎并非如此<file src=*.dll" target="lib\net35" />。如果我有一个像这样的元素将所有 dll 复制到包中，则会导致实现此包的程序集引用 \net35 目录中的所有程序集。这不是我想做的。我期望有一些魔法，只有“引用”中指定的程序集才会被实际引用，而所有其他程序集将保留在分解的 \packages 文件夹中，并且应用程序将工作，因为所有 dll 都位于同一目录中。也许我错了......
尝试#2 作为内容添加到项目中如果我在打包时将未引用的程序集放入 \content\lib 而不是 lib\net35 中，则会在项目中创建一个 \lib 文件夹，并将 \content\lib dll 直接转储到该项目中，然后强制我们将它们签入源代码管理。它可以按我想要的方式工作、编译和运行，但是我真的不希望将它们存储在项目的 \lib 文件夹中。
我正在寻找一种解决方案，其中项目获取对“A”的引用，并且仍然可以与位于同一位置但不直接引用的其他所需程序集一起运行。看起来尝试 #1 是正确的路径，但也许存在错误？
仅供参考，我输入了这个作为 NuGet 的问题 http://nuget.codeplex.com/workitem/2704直接看到团队也有答案。
这是 Nuget 2.1 中引入的错误，后来在 2012 年 12 月发布的 Nuget 2.2 版本中修复。
在原始发布中使用尝试 #1 现在可以正常工作。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
