问题描述
试图找出在开发环境中使用Nuget来管理我们自己的库的最佳方法。
我们希望标准化Nuget为我们的第三方库提供服务的方式，但也希望使用Nuget来管理内部实用程序库，以供使用in的开发人员使用房子库，这很棒，每个人都很高兴。但是，对于正在积极使用Utility lib的开发人员来说，问题似乎更加严重，他们以前的build lib，build main app，F5和go的过程现在因发布，更新和可能的许多软件包而变慢，更不用说抱怨额外的过程！
我们在内部库上使用TDD，但每个人都需要能够与主应用程序一起调试和修改库，已经看过Phil Haacks在1.3版调试包中的演示并阅读了David Ebbos博客，但这适合不同的情况。
那么开发/调试周期的最佳过程是什么？如果要使用Nuget，那么我们需要接受现有的约束，或者人们是否正在使用一种混合实践，也许1.3接近于将所有这些自动化，或者我们只是避免将Nuget用于内部软件包，这真是可耻。 p>
喜欢Nuget，也许想从小家伙那里得到很多，反馈表示赞赏。
谢谢
我建议您使用单独的网络共享或供稿（类似于在云中支持）针对不同情况。
您可以想象创建一个CI共享，一个QA共享，一个Releases共享，...
让引用的库中的人员进行CI生成下降例如，CI信息库上的CI软件包，并已被其他项目拾取（只需进行简单的更新，就可以通过PowerShell在预构建中进行自动化：检查新版本，如果需要，请更新）。
请确保在发布产品里程碑时，它们也以已发布的依赖项进行发布（可能就像切换feed一样简单，发布的版本号总是比CI版本更高）
希望有帮助！
欢呼声，
Xavier
Trying to figure out the best way to use Nuget in a development environment to manage our own libraries.
We want to standardize on Nuget way of doing things for our 3rd party libs, but would also like to use Nuget to manage our internal utility libraries, for developers consuming the in house libs this is great and everyones happy. However, for devs actively working on the Utility lib it seems to be more problematic, their previous process of build lib , build main app , F5 and go is now slowed down with publishing, and updating and potentially lots of packages, not to mention the moaning about additional process!
We use TDD on the internal libs but everyone needs to be able to debug and modify libs along with main app, have seen Phil Haacks demo on debug packages in 1.3 and read David Ebbos blog, but that fits different scenario.
So what is the best process for dev/debug cycles? if to use Nuget then we need to accept the existing constraints, or is there a hybrid practice people are using and maybe 1.3 gets closer to automating all this, or do we just avoid Nuget for internal packages which would be a real shame.
Loving Nuget, maybe wanting way to much from the little guy, feedback appreciated.
Thanks
I'd suggest you use separate network shares or feeds (similar to what myget.org supports in the cloud) for different scenarios.You could imagine creating a CI share, a QA share, a Releases share, ...
Make people working on the referenced library do CI builds that drop CI packages on the CI repository for instance, and have them picked up by other projects (who just need to do a simple update, could be automated through PowerShell in pre-build: check for new version, if so, update).
Just make sure that when products release their milestones, they also release with released dependencies (could be as simple as switching feeds, releases will always have a higher version number than CI builds).
Hope that helps!Cheers,Xavier
这篇关于在开发环境中使用Nuget-最佳做法/方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！