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，只能从该解决方案中做到。”

似乎有一个issue on 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

我通过更改项目文件中的提示路径以包含$（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作为您引用的单独程序集，并且具有自己的依赖项而不是其所在的解决方案。

通过这样做，你可以保护公共区域不被foo或bar更新引用的包并打破它。

Answer 4

在我们的案例中，许多开发人员和解决方案都使用tfs，并且在不同的分支中有多个版本... 并且每个开发人员都知道源必须在哪里。

在这种情况下相对路径不起作用，在重合盘的情况下的绝对路径被相对替换并且也不起作用。

我们的解决方案在于摆脱相对路径。如果将NuGetPackages放在单独的磁盘上，则可以执行此操作。像这样：

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

您不会的任何文件夹名称之后，您可以在NuGet.Config

中指定realy绝对路径

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

毕竟删除suo文件

ps：如果他们住在sourcecontrol中，那么改变现有解决方案会有点麻烦最简单的方法是在每个.csproj中更正p：\ NuGetPackages的路径否则，有必要重新安装所有引用并手动撤消sourcecontrol中标记为已删除的所有packages.config

NuGet和多种解决方案

4 个答案: