.net 使用Nuget高效的开发工作流？

Nuget是一个很好的工具，但它似乎使同时迭代修改库和宿主应用程序的常见过程变得复杂

例如，在应用程序中，如果我们有应用程序本身和5个Nuget软件包，并且我们希望开始更改其中3个Nuget软件包。似乎只有有限的有效选择

情景1： 加载Visual Studio的4个副本（一个用于应用程序，一个用于每个软件包），修改软件包，等待生成软件包，更新、修改主机、生成、清洗和重复

情景2： 在主应用程序中，删除Nuget依赖项并添加项目文件，然后高效地进行迭代。但是，一旦您对软件包满意，就需要修复解决方案/项目文件（Nuget Restore等）

---

我们错过了什么？在开源世界中，这是一个简单的过程。

NuGet是一个很好的版本库工具，可以作为独立的包进行开发、测试和发布。如果您可以将它们视为一个产品，包含功能请求、bug修复和工作计划，那么NuGet将支持发布新版本供系统使用

如果您的库与系统耦合，因此功能被添加到库中以直接支持特定系统的新功能，那么您可能希望使库成为该系统发布和开发过程的一部分。您可以在编写库时考虑到系统，将其作为系统的一部分进行测试，然后作为系统部署过程的一部分通过NuGet发布它。在开发过程中，这些库只是项目参考，并且会立即更新

---

本质上，您必须将其视为系统的一个组件或作为一个孤立的产品；试图将两者都视为一个错误。

这很难简明扼要地回答。你能解释一下你想用NuGet解决什么问题吗？你所说的“开始更改三个NuGet软件包”到底是什么意思？你没有真正清楚地描述你在做什么。如果您有一个单一的解决方案，它是4个NuGet软件包的源代码，并且有一个应用程序使用它们，那么我只会使用项目引用，而不是NuGet引用-这不需要任何“修复”…而且，我非常确定NuGet符合“开源”的条件：。不过，我不确定我是否理解其中的关联性。这相当直截了当，所以请原谅我不清楚。我们有希望在整个公司使用的库，因此，内部使用Nuget。然而，我们也不想仅仅为了测试我们的应用程序而经历Nuget发布周期。我们想要单一解决方案的便利性，但需要Nuget的强大功能。显然，如果我们的应用程序解决方案中引用了Nuget包，那么我们就不能对Nuget管理的库进行简单的迭代。这显然是标准的工作流程，但如果没有大规模的出版周期，我找不到方便的库更改的答案。@halt00您找到问题的答案了吗？我正在寻找相同的解决方案，但无法进入其中，在我的情况下，我希望核心开发人员有项目解决方案，而前端开发人员只有带有nuget包的网站