Nu Get&；多个解决方案引用的项目的项目级别相关性问题

本文关键字：项目 问题 相关性 引用 解决方案 Get amp Nu | 更新日期: 2023-09-27 17:58:44

我正在努力找出处理这种情况的最佳方法

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

NuGet之前

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

使用NuGet

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

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

Nu Get&；多个解决方案引用的项目的项目级别相关性问题

当我去了解Chris B是否为此创建了NuGet问题时，我找不到。编辑：他做到了，见下面的评论。但我确实发现了NuGet的一个半文档化的功能，我用来解决这个问题：允许指定安装包的文件夹

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

  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:

让我从两个角度来阐述这一点。这适用于VisualStudio和TFS——我将把SVN留给其他人来解决。

首先：如果你的驱动器上没有源代码，并且做了一个解决方案（而不是一个项目），我更喜欢这样做，这样你就可以获得解决方案需要构建的一切。不应该有任何遗漏的引用去手动抓取。我们可以通过将包文件添加为解决方案项来完成这么多工作。是的，在每个解决方案中。是的，做了一些工作，但完成后，包文件将自动从源代码管理中获取/更新。

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

我的解决方案摘要：

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

*一旦一个解决方案将包更新为新的路径或文件名，它们将显示为对其他解决方案的缺失引用，您必须手动清理。但至少你知道包在源代码管理中的位置"（与RandomSolution''packages的位置相反）

包总是存储在解决方案级别，因此如果将一个包安装到多个项目中，它们来自同一个位置。我不相信你可以配置它，使每个项目都有自己的包文件夹。

我不确定有什么好方法可以做你正在尝试的事情。你也许可以在获取包的项目上有一个构建步骤，但我不知道这对你有多合适。

我建议在NuGet Issue Tracker上发帖，以便展开讨论。从事这项工作的人似乎很活跃，所以他们可能会在未来的版本中添加对它的支持：-）

相关文章：