Nuget是一个很棒的工具，但它似乎使同时迭代修改库和托管应用程序的常见过程复杂化。
例如，在应用程序中，如果我们有app本身和5个Nuget包，我们想要开始更改三个Nuget包。似乎有限的有效选择。
场景1： 加载4个Visual Studio副本（一个用于应用程序，一个用于每个软件包），修改软件包，等待软件包构建，更新，修改主机，构建，冲洗和重复。
场景2： 在主应用程序中，删除Nuget依赖项并添加proj文件并有效地迭代。但是，一旦你对软件包感到满意，就需要修复解决方案/ proj文件（Nuget恢复等）。
我们在这里缺少什么？在开源世界中，这很容易。
答案 0 :(得分：2)
NuGet是版本库的好工具，可以作为独立的包进行开发，测试和发布。如果您可以将它们视为产品，包括功能请求，错误修复和工作计划，那么NuGet将支持发布要使用的系统的新版本。
如果您的库与系统耦合，例如将功能添加到库中以直接支持特定系统的新功能，那么您可能希望使库成为该系统的发布和开发过程的一部分。您可以在编写系统时考虑系统，将其作为系统的一部分进行测试，然后通过NuGet将其作为系统部署过程的一部分进行发布。在开发过程中，库只是项目引用并立即更新。
基本上，您必须将其视为系统的一个组成部分或作为一个孤立的产品;尝试将其视为两者都是错误的。