NuGet和多种解决方案

Question

我们有两个解决方案:foo.sln和bar.sln

我有一个foo和bar都使用的公共库.两者都使用Common.csproj.

如果我打开foo并更新nuget引用,Common.csproj中的所有引用都指向foo/packages /.如果我稍后打开bar并更新nuget引用,则所有引用都将设置为bar/packages /中的引用.当然,这会让foo团队感到愤怒,因为它会导致Common.csproj和Foo特定的东西之间不兼容,比如Foo.Data.csproj,它仍然指向foo/packages.

必须有一些明显的解决方案,除了:"创建一个包含所有项目的巨大解决方案,如果你需要触摸nuget,只能从该解决方案中做到."

在codeplex上似乎存在一个问题,(顺便提一下,这是最高投票的问题),但显然我太过于无法理解这个问题是如何解决的.有人可以解释如何解决这个问题吗？

Answer 1

这个问题先于NuGet.如果您在两个解决方案中引用了一个项目,并且在一个解决方案中打开项目时更改了项目中的程序集引用,那么当它在另一个解决方案中打开时,它将更改该项目的引用路径.无论引用如何更改(使用NuGet或其他方式),情况始终如此.

但真正的问题是,当您进行更新时,更新的软件包不会出现在foo/packages目录中吗？

简单的解决方案是将Common.csproj移动到它自己的解决方案中,具有自己的引用,包文件夹,构建和发布过程.然后使用内置的任何相关依赖项创建自己的NuGet包.然后你可以将你的Common软件包安装到Foo和Bar中,然后Foo团队可以在它们准备就绪时自由更新到最新版本的Common.

我听到的主要论点是,您可能希望在调试时单步执行Common代码,但这不再是Visual Studio 2010的问题.

您需要问的基本问题是谁拥有Common.csproj？是Foo团队还是Bar团队？

Answer 2

我通过更改项目fil中的提示路径以包含$（SolutionDir）变量来解决此问题：

Reference Include="EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <HintPath>$(SolutionDir)packages\EntityFramework.6.1.3\lib\net40\EntityFramework.dll</HintPath>

Answer 3

为什么不将 common.csproj 作为您引用的单独程序集，并拥有自己的依赖项，而不是其所在解决方案的依赖项。

通过这样做，您可以保护 common 免受 foo 或 bar 更新引用的包并破坏它的影响。