NuGet使用git子模块时自动恢复包 [英] NuGet Automatic Package Restore when using git submodules

问题描述

我试图了解在Github上托管引用库时是否有任何方法依赖于Nuget Automatic Package Restore。问题是，当我添加某个库作为子模块时，它拥有它自己的/ packages /目录。但是，当我将该库中的csproj添加到我的解决方案中时，因为该子模块的/ packages /目录中没有任何DLL，所以构建失败。

显然，机器是从我已经引用的子模块打开.sln文件，做一个构建。现在，从我的主要解决方案构建显然将工作，因为submodule中的/ packages /文件夹已填充。但是，这不是我可以在构建服务器上做的事情。

解决此问题的任何方法都不会完全搞乱子模块？我显然也不想更改submodule .csproj，因为这会使它与原点不同步。理想情况下，如果我可以指示nuget将引用的子模块.csproj放在它自己的/ packages /目录中，我会很乐意。

有两种类型的自动包恢复。在Visual Studio中构建解决方案时触发的一种方法，以及基于MSBuild并需要修改项目才能将NuGet.exe还原作为构建的一部分运行的一种方法。基于MSBuild的恢复是通过选择启用NuGet包恢复来启用的，但NuGet团队已经弃用这个恢复。

对于构建服务器，您需要执行以下任一操作： / p>

1. 运行构建之前，为所有解决方案运行 NuGet.exe还原 li>
   
2. 通过MSBuild恢复NuGet包作为主要解决方案。

恢复NuGet使用MSBuild的软件包可以使用基于MSBuild的NuGet软件包还原，或者更好的方法是创建一个Before.YourSolution.sln.targets文件，如 Ultimate Cross Platform NuGet Restore 后。自定义Before .... targets文件需要恢复子模块的包。

如果您使用基于MSBuild的恢复，则其中一个好处是不存在在构建解决方案之前需要先运行预构建步骤，因为构建解决方案可以执行还原。基于MSBuild的软件包还原的问题之一，至少在Visual Studio中选择启用NuGet软件包还原时启用的问题之一是，它可能会导致使用自己的自定义MSBuild .targets文件的NuGet软件包出现问题。 p>

I am trying to understand if there is any way to rely on Nuget Automatic Package Restore when referencing libraries hosted on Github. The problem is that when I add certain library as submodule, it has it's own /packages/ directory. But, when I add csproj from that library into my solution since there are no DLLs in /packages/ directory of that submodule, build fails.

Obviously, easy fix on my machine is to open up .sln file from submodule that I've referenced, do a build. Now, building from my main solution will obviously work since /packages/ folder in submodule is populated. But, this is not something I can do on build server.

Any way of solving this problem without completely messing up submodule? I obviously also don't want to change submodule .csproj because that would put it out of sync with origin. Ideally I would love if I could instruct nuget to pull packages for referenced submodule .csproj in it's own /packages/ directory.

解决方案

There are two types of automatic package restore. One that is triggered when you build a solution within Visual Studio, and one that is MSBuild based and requires modifying your project to run NuGet.exe restore as part of the build. The MSBuild based restore is enabled by selecting Enable NuGet Package Restore, but this has been deprecated by the NuGet team.

For a build server you would need to do either:

1. Run NuGet.exe restore for all solutions before you run the build.
2. Have the NuGet packages restored by MSBuild as the main solution is built.

To restore the NuGet packages with MSBuild you can use the deprecated MSBuild based NuGet package restore or perhaps better is to create a Before.YourSolution.sln.targets file as described in the Ultimate Cross Platform NuGet Restore post. The custom Before....targets file would need to restore packages for the submodule.

If you use an MSBuild based restore then one of the benefits is that there is no pre-build step that someone needs to run before building the solution since building the solution does the restore. One of the problems of the MSBuild based package restore, at least with the one that is enabled when selecting Enable NuGet Package Restore in Visual Studio, is that it can cause problems with NuGet packages that use their own custom MSBuild .targets files.

这篇关于NuGet使用git子模块时自动恢复包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！