Nu-获取并解决多个解决方案引用的项目的项目级依赖性问题

Chr*_*s B 17 c# package-managers nuget

我想弄清楚处理这种情况的最佳方法是什么.

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

在NuGet之前

JSON.NET二进制文件是通过WebServiceInterface项目中的外部SVN引用的.其他依赖于WebServiceInterface的解决方案引用了项目(也作为SVN外部),因此拉动了项目及其依赖项.

使用NuGet

我还没想出如何强制将JSON.NET引用存储在WebServiceInterface项目下(而不是RandomSolution\packages位置).我发现参考@ nu-get到项目级和解决方案级别的pacakges,但是当我通过nu-get添加依赖项时,我似乎无法找到如何指定它.

这里的目标是当有人检出WebServiceInterface并将其添加到它构建的新解决方案时(而不是在JSON.NET的指向已经签入的最后一个解决方案下指向packages目录的中断的引用).

min*_*now 23

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

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

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

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

<settings>
<repositoryPath>..\..\..\Utilities\Library\nuget.packages</repositoryPath>
</settings>
Run Code Online (Sandbox Code Playgroud)

<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位置相对)."


Dan*_*eny 4

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

我不确定是否有一种好的方法可以完成您正在尝试的事情。您可能可以在获取包的项目上进行构建步骤,但我不知道这是否适合您。

我建议在NuGet 问题跟踪器中发帖以进行讨论。从事这项工作的人们似乎非常活跃,因此他们可能可以在未来的版本中添加支持:-)