尝试找出在开发环境中使用Nuget来管理我们自己的库的最佳方法。
我们想要为我们的第三方库标准化Nuget的服务方式，但是也想使用Nuget来管理我们的内部实用程序库，对于使用内部库的开发人员来说，这很棒并且每个人都很开心。但是，对于开发人员积极开发Utility lib似乎更有问题，他们之前构建lib，构建主应用程序，F5和go的过程现在因发布，更新和潜在的大量软件包而变慢，更不用说抱怨额外的过程！
我们在内部库中使用TDD，但每个人都需要能够与主应用程序一起调试和修改库，已经在1.3中的调试包中看过Phil Haacks演示，并阅读David Ebbos博客，但这适用于不同的场景。
那么开发/调试周期的最佳流程是什么？如果要使用Nuget，那么我们需要接受现有的约束，或者是否有人正在使用的混合实践，并且1.3可能更接近自动化所有这些，或者我们只是避免Nuget用于内部包，这将是一个真正的耻辱。
Loving Nuget，也许想要从小家伙那里得到很多，反馈意见。
由于
答案 0 :(得分：3)
我建议您使用单独的网络共享或提要（类似于云中支持的myget.org）用于不同的方案。 您可以想象创建CI共享，QA共享，发布共享，......
让人们在引用的库上工作做CI构建，例如在CI存储库中删除CI包，并让其他项目（只需要进行简单更新）的人员可以通过预先通过PowerShell实现自动化build：检查新版本，如果是，请更新）。
只要确保当产品发布其里程碑时，它们也会发布已发布的依赖项（可能就像切换源一样简单，版本的版本号总是比CI版本更高）。
希望有所帮助！ 干杯， 泽维尔
答案 1 :(得分：1)
如果您正在同时处理lib和主应用程序的源代码，我会说NuGet可能不是一个好的解决方案。我认为它只适用于您使用库的“稳定”版本而不需要在主应用程序开发期间经常更改的情况。
那就是说 - 你的图书馆的开发可能是孤立的吗？你已经提到过你在lib上做TDD了，为什么不能完成这项工作，然后构建，部署，然后完成主应用程序工作？