试图找出在开发环境中使用Nuget来管理我们自己的库的最佳方法 .
我们想要为我们的第三方库标准化Nuget的服务方式，但是也想使用Nuget来管理我们的内部实用程序库，对于使用内部库的开发人员来说，这很好，每个人都很开心 . 但是，对于开发人员积极开发Utility lib似乎更有问题，他们之前构建lib，构建主应用程序，F5和go的过程现在因发布，更新和潜在的大量软件包而变慢，更不用说抱怨额外的过程！
我们在内部库中使用TDD，但每个人都需要能够与主应用程序一起调试和修改库，已经在1.3中的调试包上看过Phil Haacks演示并阅读David Ebbos博客，但这适合不同的场景 .
那么开发/调试周期的最佳过程是什么？如果要使用Nuget，那么我们需要接受现有的约束，或者是否存在人们正在使用的混合实践，并且1.3可能更接近自动化所有这些，或者我们只是避免Nuget用于内部包，这将是一个真正的耻辱 .
爱的Nuget，也许想从小家伙那里得到很多，反馈赞赏 .
谢谢
3 回答
我建议你使用 separate network shares or feeds （类似于 Cloud 中支持的myget.org） for different scenarios . 您可以想象创建CI共享，QA共享，发布共享，......
让人们在引用的库上工作做CI构建，例如在CI存储库上删除CI包，并让其他项目（只需要进行简单更新，可以通过PowerShell在预构建中自动化）进行选择：检查对于新版本，如果是，请更新） .
只要确保当产品发布其里程碑时，它们也会发布已发布的依赖项（可能就像切换订阅源一样简单，版本的版本号总是比CI版本更高） .
希望有所帮助！干杯，泽维尔
如果您同时处理lib和主应用程序的源代码，我会说NuGet可能不是一个好的解决方案 . 我认为它只适用于您使用库的“稳定”版本而不需要在主应用程序开发期间经常更改的情况 .
那就是说 - 您的图书馆的开发是否可以孤立地完成？你已经提到过你在lib上做TDD了，为什么不能完成这项工作，然后构建，部署，然后主应用程序工作完成了？
我同意如果您在源代码管理库中使用多个分支，Nuget不是最好的方法 .
我对此做了一个跟踪，无法找到如何自动切换Feed并获得项目的最新Nuget包而不会产生任何开销 .
我们在TFS中有三个分支，遵循敏捷过程 .
我怎么看它的工作原理：如果开发人员在dev分支上开发并更新Nuget feed，我们就会在发布时合并到INT分支 . 有一个自动构建过程，但是它们的代码项目需要能够告诉包有更新，所以我在项目中实现了更新并安装了预构建步骤 . 现在问题是项目总是更新，并且存在任何发生的构建总是会拉出最新的nuget包的风险，即使你不想要它 .
我似乎无法弄清楚如何以编程方式选择何时更新包 .