我正在寻找开发和测试私有nuget包的实用选项。
我们有一组通过Azure工件提要安全地交付的“核心”代码。我们有各种使用核心nuget包的“消费”应用程序。
作为一个中小型团队，一个人可能在开发核心nuget的同时也在消耗它。
今天我们签入/合并nuget包的代码。确保Pull请求被批准/通过。然后构建更新Azure工件提要。
然后我们回到“消费”app，可以更新包。如果您第一次修复/添加该功能，效果会很好。但是，当将其视为迭代开发方法时，会减慢生产率。
为一个小团队寻找简单的选择。期权随想:
>
将nuget“Alpha”包直接从开发者的机器推到Azure工件feed。也是符号服务器？
用Azure构建允许“特性”分支以某种方式发布到Azure工件提要上吗？
推到当地的nuget feed。包括PDB以便可以对其进行调试？
临时中断直接用于dll本地副本的nuget引用？
重新考虑使用nuget包作为一个整体？
将nuget“Alpha”包直接从开发者的机器推到Azure工件feed。也是符号服务器？
这取决于您是否需要调试它。如果您需要调试这个“alpha”包，您必须将符号包推送到符号服务器。
注意:您不需要将“alpha”包推送到符号服务器，只需要将符号包推送到。
用Azure构建允许“特性”分支以某种方式发布到Azure工件提要上吗？
有一个任务Push NuGet packages，我们可以使用它在构建期间发布到Azure工件提要，无论它在哪个分支上。这取决于您是否对Azure工件提要有足够的权限，您可以从工件->设置->提要设置->权限中进行检查:
推到当地的nuget feed。包括PDB以便可以对其进行调试？
不，你还得包括源代码。查看此线程以了解更多细节。
并且有一个轻量级的解决方案，如何在网络共享的本地提要上调试nuget包。
临时中断直接用于dll本地副本的nuget引用？
重新考虑使用nuget包作为一个整体？
答案是肯定的，当我们在本地开发项目时，使用project reference比nuget更好，查看我的另一个帖子了解更多细节:
票:项目参考VS NuGet。
希望这能帮上忙。
