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上存在一个问题（顺便说一句，是最受欢迎的问题），但显然我太蠢了，无法理解如何解决此问题。有人能解释如何解决这个问题吗？

- Code Silverback

---

我想知道这是否突然成为一个问题，因为我已经做了几个月而没有遇到问题，昨天左右有一个更新，我们在24小时内突然都遇到了它。或者这只是巧合。 - GraemeF

请参见https://dev59.com/Q2015IYBdhLWcg3w_Q0_#7908976。该文章描述了如何更改配置以指定解决方案存储其文件的位置。如果您将所有解决方案指向同一个目录，则无论使用哪个解决方案，提示路径都应该是正确的。 - Reed Rector

@ReedRector，你应该将链接放在答案中，而不仅仅是评论中。 - Michael Freidgeim

Answer 1

这个问题在 NuGet 出现之前就已经存在。如果你有一个被两个解决方案引用的项目，并且在其中一个解决方案中打开该项目并更改程序集引用，当你在另一个解决方案中打开该项目时，它当然会更改该项目的引用路径。不管是怎么更改引用（使用 NuGet 还是其他方式），这种情况一直存在。

但真正的问题是，当你更新后，更新的包不会出现在 foo/packages 目录中，对吧？

简单的解决方案是将 Common.csproj 移动到自己的解决方案中，具有自己的引用、packages 文件夹、构建和发布过程。然后创建自己的 NuGet 包，其中包含任何相关依赖项。然后你可以将你的 Common 包安装到 Foo 和 Bar 中，这样 Foo 团队就可以随时更新到最新版本的 Common。

我听到的主要反对意见是你可能想要在调试时浏览 Common 代码，但这在 Visual Studio 2010 中已不再是问题。

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

- Daniel Dyson

---

这是我见过的最好的解释。如果我可以投十次票，我一定会这样做。 - ferventcoder

刚遇到了这种情况，很可能会采用这个解决方案（一直在拖延）。 - Sumo

我刚刚发现NuGet 2.1可以解决这个问题。http://docs.nuget.org/docs/release-notes/nuget-2.1#Specify_%e2%80%98packages%e2%80%99_Folder_Location - Sumo

Answer 2

我通过在项目文件中更改提示路径来解决了问题，使其包含$(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>

- Rolf

Answer 3

在我们的情况下，有许多使用TFS的开发人员和解决方案，不同分支中有多个版本...每个开发人员都有自己对源代码位置的理解。

相对路径在这种情况下无法工作，如果磁盘符号相同，则绝对路径会被替换为相对路径，但也无法工作。

我们的解决方案是摆脱相对路径。您可以通过将NuGetPackages放在单独的磁盘上来实现此目的。就像这样：

net use /persistent:yes p: \\localhost\C$\NuGetPackagesDiskFolder

任意文件夹名称都可以。 在此之后，您可以在NuGet.Config中指定真正的绝对路径。

<config>
<add key="repositorypath" value="p:\NuGetPackages" />
</config>
<packageRestore>
<add key="enabled" value="True" />
</packageRestore>

删除所有suo文件

备注：如果现有解决方案存在于源代码控制中，则更改会有一些麻烦，最简单的方法是在每个.csproj文件中更正路径为p:\NuGetPackages。否则需要重新安装所有引用，并手动撤消源代码控制中标记为已删除的所有packages.config。

- aple

Answer 4

为什么不将common.csproj作为一个独立的程序集，您可以引用它并拥有自己的依赖项，而不是与所在解决方案的依赖项相同。

这样做可以保护common不受foo或bar更新所引用的包并破坏它的影响。

- Nathan