在开发环境中使用 Nuget - 最佳实践/如何
试图找出在开发环境中使用 Nuget 来管理我们自己的库的最佳方法。
我们希望标准化 Nuget 为我们的第 3 方库做事的方式，但也希望使用 Nuget 来管理我们的内部实用程序库，对于使用内部库的开发人员来说，这很棒，每个人都很高兴。然而，对于积极开发 Utility lib 的开发人员来说，问题似乎更大，他们以前的构建 lib 、构建主应用程序、 F5 和 go 的过程现在随着发布、更新和潜在的大量软件包而减慢，更不用说抱怨额外的过程！
我们在内部库上使用 TDD，但每个人都需要能够与主应用程序一起调试和修改库，已经看过 Phil Haacks 在 1.3 中调试包的演示，并阅读了 David Ebbos 博客，但这适合不同的场景。
那么开发/调试周期的最佳流程是什么？如果要使用 Nuget 那么我们需要接受现有的限制，或者人们正在使用混合实践，也许 1.3 更接近于自动化这一切，或者我们只是避免使用 Nuget 作为内部包，这将是一个真正的耻辱。
喜欢 Nuget，也许想从这个小家伙身上得到很多东西，感谢反馈。
谢谢
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议您使用单独的网络共享或提要（类似于myget.org支持云端）针对不同场景。
您可以想象创建一个 CI 共享、一个 QA 共享、一个发布共享……
让处理引用库的人员进行 CI 构建，例如将 CI 包放到 CI 存储库上，并让其他项目（谁只需要做一个简单的更新，可以在预构建中通过 PowerShell 自动执行：检查新版本，如果有，则更新）。
只需确保当产品发布其里程碑时，它们也会发布已发布的依赖项（可能就像切换源一样简单，发布版本始终比 CI 版本具有更高的版本号）。
希望有帮助！
干杯，
泽维尔
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 可能不是一个好的解决方案。我认为它只适用于您使用库的“稳定”版本的情况，并且在主应用程序的开发过程中不需要频繁更改。
也就是说，您的库的开发是否可以单独完成？您已经提到您正在库上进行 TDD，那么为什么不能完成该工作，然后构建、部署，然后完成主应用程序工作呢？
If you're working on the source code for the lib and the main app at the same time, I'd say NuGet is probably not a good solution. I think it'll only work in situations where you work with a "stable" version of the library that don't need to change frequently during the development of your main app.
That said - is it possible the development on your library could be done in isolation? You already mention you're doing TDD on the lib, so why can't that work be done, then built, deployed, then the main app work done?