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

考虑这个回购/文件结构，我们的解决方案...NuGet可以在同一个解决方案中使用每个项目包的下载路径吗？

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在没有任何问题的情况下处理此问题，提示您在对解决方案执行提交时正在更新多个回购站。这很好，而且正是我们想要的。

但是我们遇到的问题是NuGet。根据我们的理解，NuGet.config（以及阅读/应用它们的层次结构/优先级）与解决方案文件相关，因此项目的NuGet引用也会相应更新。这会导致以下问题：当您在App1.sln中工作时，对Shared1.dll中的NuGet包的引用与Shared.dll中的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使用的包中app1packages去走。

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

来源

2015-05-20 MarqueIV

正如你怀疑这是不可能的。 NuGet目前总是检查与解决方案目录相关的NuGet.Config文件。因此，如您所做的那样，将单独的存储库检出到指定的相关目录可能是唯一的解决方案。 –

如果您为共享项目创建解决方案，则所有项目都将在其父项中引用一个包文件夹。然后你可以合并你的应用程序和共享项目，他们都将使用适当的相对引用。 – Kiliman

我原本以为是这样，但是当你将它们带回到一个解决方案时（例如App1），NuGet完全搞砸了，不知道从哪里拉东西。更新也不起作用。 – MarqueIV

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

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

在我的项目中，我创建了一个.nunit文件夹，并在每个项目中引入了nuget.exe，并因此引用了dll。

最后但并非最不重要的每个项目都需要通过使用nuget来恢复软件包。的csproj像这样：

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

的东西从所有这一切带走的是对的NuGet和自动包修复的图形工具（工具 - >选项 - >的NuGet）不能在为了实现目标依赖在这里描述。

来源

2017-01-05 14:22:16 xDisruptor

我喜欢你的'BeforeBuild'解决方案。不像我说的那样正确地做我想要的，你现在不能使用图形工具，所以修改包不能从命令行完成，但仍然是这样，所以我要把它标记为回答。（而且现在它已经很疯狂了:) – MarqueIV

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

回答

相关问题