如何在Visual Studio解决方案之间共享外部依赖关系? [英] How do you share external dependencies between Visual Studio solutions?

问题描述

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

I have a Java background so I’m used to having Maven handle all problem around downloading and keeping dependencies up to date. But in the .NET environment I have not yet found a good way to manage all these external dependencies.

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

The main problem here is that I mass produce solutions and they all tend to depend on the same third party dll’s. But I don’t want to maintain separate copies of each component under each solution. So I need a way of linking all the different solutions to the same set of dll’s.

我意识到一种解决方案可能是将外部库包含在所有解决方案中都包含的库项目"中，然后让其他项目通过它来引用它们. (或者确保对所有项目都引用同一位置的外部dll.)

I realized that one solution might be to include the external libraries in a "library project" that is included in all solutions and let the other projects references them through it. (Or just make sure to reference the external dll’s from the same place for all projects.)

但是还有更好的方法吗? (最好使用Visual Studio的某种插件.)

But are there any better ways to do this? (Preferably using some sort of plug-in for Visual Studio.)

我查看了 Visual Studio Dependency Manager ，它看起来很完美，但是有人尝试过它是真的吗?我也看过Maven的.NET端口，但是不幸的是，我对这些端口的状态并没有太深刻的印象. (但是，如果您认为我应该再试一次，请继续推荐他们.)

I’ve looked at the Visual Studio Dependency Manager and it seems like a perfect match but have anyone tried it for real? I’ve also seen the .NET ports of Maven, but unfortunately I was not too impressed by the status of those. (But please go ahead and recommend them anyone if you think I should give them another try.)

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

So what would be the smartest way to tackle this problem?

更新:

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

I realized that I needed to explain what I meant with linking to the same set of dll’s.

我要在此处实现的目的之一是避免不同的解决方案引用每个组件的不同版本.如果我将组件更新到新版本，则应在下次构建时针对所有解决方案对其进行更新.这将迫使我确保所有解决方案都是最新的组件.

One of the things I'm trying to achieve here is to avoid that the different solutions are referencing different versions of each component. If I update a component to a new version, it should be updated for all solutions upon next build. This would force me to make sure all solutions are up to date with the latest components.

更新2: 请注意，这是在 NuGet 或

Update 2: Note that this is an old question asked before tools like NuGet or OpenWrap existed. If anyone is willing to provide a more up-to-date, please go ahead and I will change the accepted answer.

推荐答案

1. 找到一些地方来存储程序集.例如，我以如下方式存储.Net核心程序集:

1. Find some place to store the assemblies. For example, I store the .Net core assemblies like so:

• > \ NetFX \ 2.0527 \ *
• > \ NetFX \ 3.0 \ *
• > \ NetFX \ 3.5 \ *
• > \ NetFX \ Silverlight 2 \ *
• > \ NetFX \ Silverlight 3 \ *

• <branch>\NetFX\2.0527\*
• <branch>\NetFX\3.0\*
• <branch>\NetFX\3.5\*
• <branch>\NetFX\Silverlight 2\*
• <branch>\NetFX\Silverlight 3\*

使用MSBuild中的ReferencePath属性(或Team Build中的AdditionalReferencePath)将您的项目指向适当的路径.为了简单和易于维护，我有1个* .targets文件，它知道每个这样的目录；我所有的项目导入该文件.

Use the ReferencePath property in MSBuild (or AdditionalReferencePath in Team Build) to point your projects at the appropriate paths. For simplicity and easy maintenance, I have 1 *.targets file that knows about every such directory; all of my projects Import that file.

编辑

为回答问题中的更新，让我再增加一个步骤:

In response to the update in the question, let me add one more step:

4)确保每个项目文件中的每个程序集引用都使用完整的.Net强名称​​，并且没有其他.

4) Make sure every assembly reference in every project file uses the full .Net strong name and nothing else.

坏:

<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地狱"的可能性.一旦使用了强名称，就可以在参考路径中拥有同一程序集的多个版本，因为链接器将仅加载与每个条件匹配的版本.此外，如果您决定就地更新某些程序集(而不是添加副本)，则在编译时会收到有关任何重大更改的通知，而不会在错误开始出现时通知您.

这篇关于如何在Visual Studio解决方案之间共享外部依赖关系?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！