如何防止NuGet版本在大型整体程序中（叹气:-(）应用程序（多个解决方案，每个解决方案中都有许多项目）？）？

Question

我们正在将所有解决方案构建到共享bin目录中。让不同的项目引用相同依赖项的不同版本对于我们的构建而言并不健康。

因此，我们合并了依赖项-很好。但是现在版本开始再次漂移。我们不想时不时地手动合并它们-我们想完全防止漂移。

为什么我们不想使用Paket？主要原因是看来我们将失去将NuGet包依赖项迁移到项目中新的PackageReference项的功能。因此，当前我们有package.config文件，但是我们计划用各自的PackageReferences替换它们。这意味着我们将使用msbuild的内部NuGet支持，这对于Paket似乎没有任何余地。

现在，我认为我们在这个世界上不是唯一的，其他人也有与我们相同的问题。您如何解决？

编辑1

我们有内部的NuGet存储库，但我们将其用于在Nuget.org中没有有机表示形式的依赖项以及共享我们自己的内部包。

一种方法是仅从内部NuGet存储库中使用。这具有挑战性，例如：

1. 谁将依赖项上传到那里？开发人员？但是，如何确保它们不上传相同依赖项的不同版本？敬业的人？然后它们成为瓶颈。
2. 很小，但是我们需要阻止对中央NuGet.config的提交
3. 将依赖项上载到内部NuGet存储库不是立即的。您不能只从NuGet.org下载它并上传到内部的，因为那样会丢失任何传递依赖。因此，应该围绕它建立一个过程。

这是有可能的，但是我不愿意走那条路……一定是更好的方法。

编辑2

尽管我们确实计划迁移到PackageReference，但这需要时间。不幸的是，只要我们拥有Silverlight（至少要等到第二年），专用Silverlight解决方案（80+）中的大量项目都不会迁移到PackageReference，因为这样做将无法使用VS 2015调试代码

接下来，假设我们确实迁移了所有项目，然后将所有PackageReference项目外部化为所有项目导入的单个目标文件。当按计划使用共享bin目录时，这是可行的。但是当在VS 2017中进行检查时，此设置传达了一个错误的画面，即每个项目都依赖于整个NuGet依赖项集。 我宁愿避免这种情况。

Answer 1

由于您不接受其他解决方案，因此也许可以看看paket

它是dotnet的软件包管理器，（除其他功能外）拥有解决方案范围的依赖项锁定文件。它是非常可定制的，并且在解决很多问题的同时，就像其他任何工具一样，它会创建一些新的工具。以我的经验，新的东西真是太气了：）

Answer 2

一旦转到PackageReference，就可以利用MSBuild。例如，您可以拥有a MSBuild file that contains all your dependency versions。它可能是您需要在所有<Import ... />个文件中csproj使用的文件，也可以使用Directory.Build.props。最后，在您的每个项目中，change the version number in any <PackageReference to a MSBuild variable that uses the property you previously defined。 Microsoft的大多数开放源代码存储库都使用此技术，文件名以及使用Directory.Build.props或显式<Import ... />自动导入的文件名也略有不同。

虽然您仍然可以在Visual Studio中使用“程序包管理器” UI来检查更新，但是您将无法使用它来更新程序包版本（至少，它不会保留版本的定义方式和位置） 。但是，只要确保定义版本的MSBuild文件在解决方案中即可，因此您可以在解决方案资源管理器中轻松打开该文件，然后在其中键入新的版本号。添加新的程序包引用要花些力气，但这通常是不做的通常，对于SDK样式的项目，这仍然非常容易，因为Visual Studio允许您在项目仍加载时编辑csproj。