45

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

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

如果我打开 foo 并更新 nuget 引用，Common.csproj 中的所有引用都指向 foo/packages/。如果我稍后打开 bar 并更新 nuget 引用，所有引用都会设置为 bar/packages/ 中的引用。自然，这激怒了 foo 团队，因为它可能导致 Common.csproj 和 Foo.Data.csproj 等 Foo 特定的东西之间不兼容，它仍然指向 foo/packages。

除了“创建一个包含所有项目的巨大解决方案，如果你需要接触 nuget，只能从该解决方案中进行”之外，必须有一些明显的解决方案。

在 codeplex 上似乎有一个问题，（顺便说一句，票数最高的问题），但显然我太厚了，无法理解这个问题是如何解决的。有人可以解释如何解决这个问题吗？

4

4 回答 4

38

此问题出现在 NuGet 之前。如果您在两个解决方案中引用了一个项目，并在一个解决方案中打开项目时更改项目中的程序集引用，那么当该项目在另一个解决方案中打开时，它当然会更改该项目的引用路径。无论引用如何更改（使用 NuGet 或其他方式），情况始终如此。

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

简单的解决方案是将 Common.csproj 移动到自己的解决方案中，具有自己的引用、包文件夹、构建和发布过程。然后创建您自己的 NuGet 包，并在其中内置任何相关依赖项。然后您可以将您的 Common 包安装到 Foo 和 Bar 中，然后 Foo 团队可以在他们准备好时免费更新到最新版本的 Common。

我听到的反对这一点的主要论点是，您可能希望在调试时单步执行通用代码，但这不再是 Visual Studio 2010 的问题。

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

于 2011-09-22T11:35:07.777 回答
7

我通过更改项目文件中的提示路径以包含 $(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>
于 2017-01-27T10:20:26.923 回答
1

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

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

于 2011-09-16T10:14:35.373 回答
1

在我们的案例中，许多开发人员和使用 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 文件

ps：更改现有解决方案会有点麻烦，如果它们存在于源代码控制中，最简单的方法是更正每个 .csproj 中 p:\NuGetPackages 的路径，否则需要重新安装所有 refs 并手动撤消所有 packages.config在源代码管理中标记为已删除

于 2014-10-29T04:55:13.037 回答