首页 文章

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

提问于
浏览 次
4

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

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

为了更容易地使用代码，我们将共享项目直接引入应用程序的解决方案中，这意味着例如，如果您打开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)

如您所见，这两个共享DLL来自单独的存储库，但包含在此解决方案中 . Visual Studio处理此问题没有任何问题，提示您在执行针对解决方案的提交时更新多个repos . 这很好，正是我们想要的 .

然而，我们遇到的问题是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

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

C:/Code/
    ├───Shared Trunk
    │    └─sharedpackages
    ├───App1 Trunk
    │    └─app1packages
    └───App2 Trunk
         └─app2packages

同样，我们想要的是打开App1.sln时，我们希望Shared1.dll和Shared2.dll的包进入'sharedpackages'文件夹，但App1和App1.dll使用的包进入app1包 .

那么......这可能吗？您是否可以为每个项目指定不同的NuGet包下载路径，无论它们位于哪个解决方案中？

visual-studio nuget projects-and-solutions

2 回答

  • 0

    我和/ u / MarquelV的情况相同 .

    从我的调查到nuget（至少到版本3.5）为解决这种情况提供的选项，我得出结论，必须完全忽略Visual Studio中的nuget图形工具（至少就安装/而言）恢复包，并禁用自动包恢复（工具 - >选项 - > Nuget等） . 然后在需要安装/恢复包指定应放置包的文件夹时，从命令行调用nuget.exe - 这一点很重要，因为visual studio中nuget的图形界面在存储包中是弯曲的一个“全局”存储库（通常紧邻解决方案的.sln文件） .

    在我的项目中，我创建了一个.nunit文件夹，在每个项目和参考dll中都加入了nuget.exe .

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

    <Target Name="BeforeBuild">
      <Exec Command=".\.nuget\nuget.exe restore  .\packages.config -PackagesDirectory .\packages"/>
 </Target>

    要消除这一切的原因是，为了实现此处描述的目标，不能依赖nuget的图形工具和自动包恢复（工具 - >选项 - > Nuget） .

    回复于
  • 0

    我最近遇到了类似的问题 . 就我而言，我将较小解决方案的项目组合成一个较大的解决方案 . 这些项目仍在引用其子文件夹中的包，我不想更改这些引用并打破较小的解决方案 . 我能够通过将项目包路径符号链接到解决方案级路径来解决它 .

    mklink /J .\packages ..\packages

    这有效地欺骗了项目，认为当它实际使用更大的解决方案时，它正在使用更本地版本的软件包 .

    情况并非完全相同，但足够接近我希望它可以帮助某人 .

    回复于

相关问题