如何在一个大型单片应用程序中防止NuGet版本漂移（叹气：-（）应用程序中有多个解决方案，每个解决方案中有多个项目）？

我们正在构建一个共享bin目录的所有解决方案。让不同的项目引用同一依赖项的不同版本对于我们的构建来说是不健康的

所以，我们合并了依赖项-很好。但是现在版本又开始漂移。我们不希望偶尔手动合并它们-我们希望完全防止漂移

为什么我们不想使用Paket？主要原因是我们似乎将失去将NuGet包依赖项迁移到项目中新的PackageReference项的能力。因此，目前我们有package.config文件，但我们计划用相应的PackageReference替换它们。这意味着我们将使用m提供的内部NuGet支持sbuild，似乎没有给Paket留下任何位置

现在，我假设我们在这个世界上不是独一无二的，其他人也有和我们一样的问题。你如何解决这个问题

编辑1

我们有我们的内部NuGet repo，但我们将其用于在NuGet.org中没有有机表示的依赖项以及共享我们自己的内部包

一种方法是仅从内部NuGet存储库进行消费。这有一些挑战，例如：

谁在那里上传依赖项？开发人员？但如何确保他们不上传同一依赖项的不同版本？专业人员？然后他们就成了瓶颈

很小，但我们需要阻止对中心NuGet.config的提交

将依赖项上载到内部NuGet repo不是即时的。您不能仅从NuGet.org下载它并上载到内部，因为这将丢失任何可传递的依赖项。因此，应该围绕它构建一个流程

这一切都是可能的，但我不愿意走这条路……这肯定是一条更好的路

编辑2

虽然我们确实计划迁移到PackageReference，但这需要时间。不幸的是，只要我们有Silverlight（至少再过一年），专用Silverlight解决方案（80+）中的所有项目都不会迁移到PackageReference，因为这样做就不可能用VS 2015调试代码

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

---

我宁愿避免这种情况。

一旦您转到PackageReference，您就可以利用MSBuild。例如，您可以拥有。它可以是您需要在所有

csproj

文件中

的文件，也可以使用。最后，在您的每个项目中，.大多数Microsoft的开源存储库都使用这种技术，并且或者关于文件名的变体，以及它是使用

目录.Build.props自动导入的，还是显式的
导入的

尽管您仍然可以使用Visual Studio中的Package Manager UI检查更新，但您将无法使用它更新包版本（至少，它不会保留版本的定义方式和位置）。但是，只需确保定义版本的MSBuild文件在解决方案中，这样您就可以在解决方案资源管理器中轻松打开该文件，然后在中键入新的版本号。添加新的包引用要稍微费劲一些，但通常不会经常这样做，而且对于SDK样式的项目来说仍然非常容易，因为Visual Studio l您可以在项目仍然加载时编辑csproj。
由于您没有接受其他解决方案，也许您可以查看

它是一个用于dotnet的包管理器，而不是（除其他功能外）保存解决方案范围内的依赖项锁定文件。它非常可自定义，虽然它解决了许多问题，但与任何工具一样，它也会创建一些新问题。以我的经验，新问题远没有那么令人恼火：）
您是否想过创建一个自定义存储库供您自己使用，您可以根据需要进行更新，以便您的项目指向自定义回购？然后根据需要控制更新。我们也有同样的问题。我们发现，定制回购协议有助于将问题最小化。到目前为止还没有完全根除。。。还在探索。你是说一个定制的NuGet提要？这是一个有趣的想法，可能会被证明是有用的。@tster-是的。至少对我们来说，创建自定义存储库确实有助于保持对版本爬行和漂移的控制。请参见编辑1。关于编辑2中的最后一条评论，我不建议将您的
PackageReference
放在外部文件中，并使您的所有项目具有相同的依赖关系。相反，您的个人
csproj
文件有一个
我们最终编写了一个工具，该工具在构建之前运行，并检查所有解决方案中所有项目的依赖关系，确保它们都是相同的。