如何在Visual Studio解决方案之间共享外部依赖项?

Ola*_*ahl 6 dependencies projects-and-solutions visual-studio

我有一个Java背景,所以我习惯让Maven处理下载和保持最新的依赖关系的所有问题.但是在.NET环境中,我还没有找到一种管理所有这些外部依赖项的好方法.

这里的主要问题是我大规模生产解决方案,而且它们都倾向于依赖于相同的第三方dll.但我不想在每个解决方案下维护每个组件的单独副本.所以我需要一种方法将所有不同的解决方案链接到同一组dll.

我意识到一个解决方案可能是将外部库包含在所有解决方案中包含的"库项目"中,让其他项目通过它引用它们.(或者只是确保从所有项目的同一个地方引用外部dll.)

但有没有更好的方法来做到这一点?(最好使用Visual Studio的某种插件.)

我看过Visual Studio Dependency Manager,它似乎是一个完美的匹配,但是有没有人尝试过真实的?我也看过Maven的.NET端口,但不幸的是我对它们的状态并没有太深刻的印象.(但如果您认为我应该再试一次,请继续向他们推荐.)

那么解决这个问题最聪明的方法是什么?

更新:

我意识到我需要解释链接到同一组dll的意思.

我试图在这里实现的一件事是避免不同的解决方案引用每个组件的不同版本.如果我将组件更新为新版本,则应在下次构建时更新所有解决方案.这将迫使我确保所有解决方案都与最新组件保持同步.

更新2: 请注意,在NuGetOpenWrap等工具存在之前,这是一个老问题.如果有人愿意提供更新,请继续,我将更改已接受的答案.

Ric*_*erg 2

  1. 找到一些地方来存放组件。例如,我像这样存储 .Net 核心程序集:

    • <branch>\NetFX\2.0527 \*
    • <branch>\NetFX\3.0 \*
    • <branch>\NetFX\3.5 \*
    • <branch>\NetFX\Silverlight 2 \*
    • <branch>\NetFX\Silverlight 3 \*
  2. 使用MSBuild 中的ReferencePath 属性(或Team Build 中的AdditionalReferencePath)将项目指向适当的路径。为了简单和易于维护,我有 1 个 *.targets 文件,它知道每个这样的目录;我的所有项目导入该文件。

  3. 确保您的版本控制策略(分支、合并、本地<->服务器映射)保持项目和参考路径之间的相对路径不变。

编辑

为了回应问题中的更新,让我再添加一步:

4) 确保每个项目文件中的每个程序集引用都使用完整的 .Net 强名称,而不使用其他任何内容

坏的:

<Reference Include="Microsoft.SqlServer.Smo">
  <SpecificVersion`>False</SpecificVersion>
  <HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\100\Shared\Microsoft.SqlServer.Smo.dll</HintPath>
</Reference>
Run Code Online (Sandbox Code Playgroud)

好的:

<Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" />
Run Code Online (Sandbox Code Playgroud)

后一种格式的优点:

  • 在协作开发环境中使用 HintPath 将不可避免地导致“它对我有用”但对其他人不起作用的情况。特别是你的构建服务器。省略它会强制您使引用路径正确,否则将无法编译。
  • 使用弱名称可能会导致“DLL 地狱”。一旦使用强名称,那么在引用路径中拥有同一程序集的多个版本是安全的,因为链接器只会加载与每个条件匹配的版本。此外,如果您决定就地更新某些程序集(而不是添加副本),那么您将在编译时收到任何重大更改的通知,而不是在错误开始出现时收到通知。

  • 是的,如果项目足够大,足以拥有多个开发人员和多个外部依赖项,那么能够使用 MSBuild 或 MS Team Build 构建它几乎是至关重要的。关于使用强名称的旁注:我见过人们遇到麻烦,因为他们对其他(子)项目使用弱命名的 &lt;Reference&gt; 而不是使用 &lt;ProjectReference&gt;。如果您依赖于您的团队正在开发的其他项目(例如 DLL),最好将代码放在同一源代码树中(或使用 svn:externals)并使用 &lt;ProjectReference&gt;,原因与 Richard 列举的相同多于。 (2认同)