NuGet 可以在同一解决方案中使用每个项目的包下载路径吗?

Mar*_*eIV 5 projects-and-solutions visual-studio nuget

为我们的解决方案考虑这个 repo/file 结构......

Shared Repo (Checked out to D:/Shared/trunk)
    ????Shared1.dll Project
    ????Shared2.dll Project

App1 Repo (Checked out to C:/Code/App1/Trunk)
    ????App1 Project (Refs Shared1.dll project)
    ????App1.dll Project (Refs Shared1.dll and Shared2.dll projects)
    ????App1.sln

App2 Repo (Checked out to C:/Code/App2/Trunk)
    ????App2 Project (Refs Shared1.dll project)
    ????App2a.dll Project (Refs Shared1.dll and Shared2.dll projects)
    ????App2b.dll Project (Refs Shared1.dll and App2a.dll projects)
    ????App2.sln
Run Code Online (Sandbox Code Playgroud)

为了更轻松地使用代码,我们将共享项目直接引入应用程序的解决方案中,例如,如果您打开 App1.sln,这将是您的项目树...

App1.sln
    ????Shared1.dll Project
    ????Shared2.dll Project
    ????App1 Project (Refs Shared1.dll project)
    ????App1.dll Project (Refs Shared1.dll and Shared2.dll projects)
Run Code Online (Sandbox Code Playgroud)

如您所见,这两个共享 DLL 来自一个单独的存储库,但包含在此解决方案中。Visual Studio 可以毫无问题地处理此问题,提示您在针对解决方案执行提交时正在更新多个存储库。这很好,这正是我们想要的。

然而,我们遇到的问题是 NuGet。根据我们的理解,NuGet.config(以及读取/应用它们的层次结构/优先级)是相对于解决方案文件的,因此项目的 NuGet 引用会相应地更新。这会导致问题,当您在 App1.sln 中工作时,Shared1.dll 和 Shared2.dll 中对 NuGet 包的引用与 App1.sln 相关,这意味着如果其他人正在 App2.sln 中工作并且尚未检查以完全相同的方式将它们的两个树干相对于彼此完全相同,参考中断。

我们对此的解决方法是始终将所有三个主干检出到与兄弟姐妹相同的文件夹中,然后将打包文件夹作为另一个兄弟姐妹,在每个解决方案旁边的 NuGet.config 中添加“../packages”。这确保引用永远不会中断,但会强制结账的位置可能是一个问题。

C:/Code/
    ????Shared Trunk
    ????App1 Trunk
    ????App2 Trunk
    ????packages
Run Code Online (Sandbox Code Playgroud)

但是,如果我们可以指定每个项目的包下载位置,我们可以将打包文件夹放置在与项目本身相关的位置,这意味着您将它们检出到哪里无关紧要。他们总能找到他们需要的包裹。是的,这意味着在我们的示例中,会有重复的包下载,但磁盘空间不是问题。代码的维护是。

C:/Code/
    ????Shared Trunk
    ?    ??sharedpackages
    ????App1 Trunk
    ?    ??app1packages
    ????App2 Trunk
         ??app2packages
Run Code Online (Sandbox Code Playgroud)

同样,我们想要的是在打开 App1.sln 时,我们希望 Shared1.dll 和 Shared2.dll 的包进入“sharedpackages”文件夹,而 App1 和 App1.dll 使用的包进入 app1packages。

所以……这可能吗?您能否为每个项目指定不同的 NuGet 包下载路径,而不管它们在哪个解决方案中?

XDS*_*XDS 1

我的情况和/u/MarquelV 一样。

从我对 nuget(至少到版本 3.5)提供的用于解决此类情况的选项的调查来看,我得出的结论是,必须完全忽略 Visual Studio 中 nuget 的图形工具(至少就安装/涉及恢复包)并禁用自动包恢复(工具 -> 选项 -> Nuget 等)。然后,只要需要安装/恢复包,指定应放置包的文件夹,就从命令行调用 nuget.exe - 这一点很重要,因为 Visual Studio 中 nuget 的图形界面倾向于将包存储在“全局”存储库(通常位于解决方案的 .sln 文件旁边)。

在我的项目中,我在每个项目中创建一个 .nuget 文件夹以及 nuget.exe,并因此引用 dll。

最后但并非最不重要的一点是,每个项目都需要通过 .csproj 使用 nuget 来恢复包,如下所示:

 <Target Name="BeforeBuild">
      <Exec Command=".\.nuget\nuget.exe restore  .\packages.config -PackagesDirectory .\packages"/>
 </Target>
Run Code Online (Sandbox Code Playgroud)

需要注意的是,不能依赖 nuget 的图形工具和自动包恢复(工具 -> 选项 -> Nuget)来实现此处描述的目标。