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

查看:102
本文介绍了如何在 Visual Studio 解决方案之间共享外部依赖项?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有 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 依赖项管理器,这似乎是完美的匹配,但有人尝试过真的吗?我还看到了 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 的含义.

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

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:请注意,这是在 NuGetOpenWrap 存在.如果有人愿意提供更新的信息,请继续,我将更改已接受的答案.

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:

  • <分支>NetFX2.0527*
  • <分支>NetFX3.0*
  • <分支>NetFX3.5*
  • <分支>NetFXSilverlight 2*
  • <分支>NetFXSilverlight 3*
  • <branch>NetFX2.0527*
  • <branch>NetFX3.0*
  • <branch>NetFX3.5*
  • <branch>NetFXSilverlight 2*
  • <branch>NetFXSilverlight 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 Server100SharedMicrosoft.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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆