17

我试图弄清楚处理这种情况的最佳方法是什么。

假设我有一个库，它被多个不同的非相关解决方案引用，我们称之为 WebServiceInterface.dll。这个库依赖于 JSON.NET。

在 NuGet 之前

JSON.NET 二进制文件是通过 WebServiceInterface 项目中的 SVN 外部引用的。其他依赖于 WebServiceInterface 的解决方案引用了该项目（也作为 SVN 外部），因此拉取了项目及其依赖项。

使用 NuGet

我还没有弄清楚如何强制将 JSON.NET 引用存储在 WebServiceInterface 项目下（而不是 RandomSolution\packages 位置）。我找到了对项目级和解决方案级包的引用 @ nu-get，但是当我通过 nu-get 添加依赖项时，我似乎无法找到如何指定它。

这里的目标是，当有人签出 WebServiceInterface 并将其添加到它构建的新解决方案中时（而不是对 JSON.NET 的损坏引用，该引用指向包目录下的最后一个解决方案是签入的）。

4

2 回答 2

23

当我去查明 Chris B 是否为此创建了 NuGet 问题时，我找不到。编辑：他做到了，请参阅下面的评论。但我确实找到了用于解决此问题的 NuGet 的半文档功能：允许指定安装包的文件夹

让我把这个问题分成2个问题：

  1. 让 NuGet 允许多个解决方案使用相同的包位置
  2. 当您包含具有 NuGet 包的项目时，让 NuGet 包自动从源代码管理中获取

问题 1：默认情况下，NuGet 将包存储在解决方案文件夹中的包文件夹中。要更改该位置，请在解决方案的根文件夹中创建一个 nuget.config 文件，其中包含以下内容：

<settings>
<repositoryPath>..\..\..\Utilities\Library\nuget.packages</repositoryPath>
</settings>

<repositoryPath>与您的解决方案相关；所以很明显，随心所欲。使每个解决方案都有自己的到相同包文件夹的相对路径。

就 NuGet 的流程而言，从那时起，repositories.config 中的路径相对于包含 repositories.config 的文件夹，而不是解决方案，因此现在所有项目/包都独立于解决方案位置进行管理。

这允许多个解决方案在源代码管理中使用相同的包，如果这些解决方案使用相同的项目（使用 NuGet 包），那么无论哪个解决方案更新包，这些解决方案/项目都将保持同步。

问题1完全解决了。

问题2：

让我从两个角度来解决这个问题。这适用于 Visual Studio 和 TFS——我将 SVN 留给其他人来解决。

首先：如果您的驱动器上没有源代码并获得解决方案（而不是项目），我更愿意这样做，以便您获得解决方案需要构建的所有内容。不应该有任何遗漏的参考资料去手动抓取。我们可以通过将包文件添加为解决方案项来做到这一点。是的，在每个解决方案中。是的，需要做一些工作，但是完成后，包文件将自动从源代码管理中获取/更新。

第二：在新的解决方案中，当您包含具有 NuGet 包的现有源代码管理项目时，您必须手动从源代码管理获取包并将它们添加为解决方案项。至少在未来获得您的解决方案的任何其他人都会自动获得成功构建所需的一切。至少对于 VS/TFS，AFAIK 就是这样。如果 projB 依赖于 projA，并且您将 projB 添加到新解决方案中，VS/TFS 不会自动从 TFS 中获取 projA。您必须手动执行此操作。因此，对于 dll 引用（如 NuGet 包）也是如此。

我的解决方案总结：

  • 所有解决方案的源代码控制中只有一个包副本
  • 任何解决方案都可以更新包，所有其他解决方案将保持同步*

* 一旦一个解决方案将包更新为新的路径或文件名，它们将显示为缺少对其他解决方案的引用，您必须手动清理它。但至少你知道包在源代码控制中的位置“（而不是 RandomSolution\packages 位置）。”

于 2011-10-26T21:11:21.100 回答
4

这些包始终存储在解决方案级别，因此如果您将一个包安装到多个项目中，它们来自同一个地方。我不相信您可以对其进行配置，以便每个项目都有自己的包文件夹。

我不确定有没有一种很好的方法来做你正在尝试的事情。您可能在获取包的项目上有一个构建步骤，但我不知道这对您有多适合。

我建议在NuGet 问题跟踪器中发布以进行讨论。从事这项工作的人似乎很活跃，所以他们可能会在未来的版本中增加对它的支持:-)

于 2011-06-19T10:54:37.663 回答