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

时间:2009-08-01 16:56:18

标签: visual-studio dependencies projects-and-solutions

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

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

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

但有没有更好的方法呢? (最好使用Visual Studio的某种插件。)

我看过Visual Studio Dependency Manager,它看起来像是一场完美的比赛,但有没有人试过它?我也看过Maven的.NET端口,但不幸的是我对它们的状态并没有太深刻的印象。 (但如果你认为我应该再试一次,请继续向他们推荐。)

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

更新:

我意识到我需要用链接到同一套dll的来解释我的意思。

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

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

3 个答案:

答案 0 :(得分:2)

  1. 找一些存放装配的地方。例如,我存储.Net核心程序集如下:

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

  3. 确保您的版本控制策略(分支,合并,本地&lt; - &gt;服务器映射)保留项目与项目之间的相对路径。你的参考路径不变。
  4. 修改

    在回答问题中的更新时,让我再添加一步:

    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>
    

    好:

    <Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" />
    

    后一种格式的优点:

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

答案 1 :(得分:1)

除了其他人所说的,它基本上归结为两件事:

  1. 确保所有开发人员都拥有相同版本的外部库
  2. 确保所有开发人员都将外部库放在同一位置(至少相对于源代码)
  3. 正如Richard Berg所指出的,您可以使用ReferencePath和/或AdditionalReferencePath来帮助解决#2问题。如果你在构建过程中使用msbuild(在我们的例子中,我们使用的是CruiseControl而不是MS Team Build),你也可以在命令行上将ReferencePath传递给它。要解决#1,我发现svn:externals非常有用(如果您使用的是SVN)。

    我对Maven的经验是,对于大多数用途来说,这样做太过分了。

答案 2 :(得分:0)

我通常在源控件上有一个单独的文件夹结构,用于extrenal或Internal依赖项,并且这些filders具有根据build或version number的程序集,例如

公共\外部\库\ NUnit的\ 2.6 \

公共\内部\库\记录器\ 5.4.312 \

并且在解决方案内部,所有需要使用任何依赖项的项目都会在公共内部或extrenal文件夹中添加对该程序集的引用。

相关问题