包管理器、项目结构和迁移
我有一个包含多个项目的解决方案，例如，10 个测试相关项目依赖于 nunit。目前我的解决方案结构包括 Tools 和 Lib 的文件夹，因此完整的 nunit 下载可能位于 Tools 中，而 dll 位于 Lib 中。
我想任何包管理器（NuGet 和 OpenWrap 是我正在考虑的两个）都需要为包创建它自己的“已知”位置。因此，尽管老式的包管理方式，在手动更新我的 Lib 文件夹后，我知道每个依赖于 nunit 的项目都已更新。
但是，如果我使用包管理器进行更新，我需要访问每个项目以确保它已更新并指向相同的引用，是吗？并且某些 dll 可能找不到（我现在正在考虑 unHDaddins），因此您还没有完全从手动包管理中解放出来。这意味着在包管理器更新每个项目之前，不会完成向最新更新的迁移。
所以我想知道我的理解是否正确，将包管理合并到规模合适的解决方案中的最佳方法是什么 - 例如：
0) add to source control: NuGet 'packages' folder or OpenWrap 'wraps' folder
1) pick a dll (start with one that you beleieve has minimal dependencies)
2) pick a project (ideally with minimal dependencies that might break)
3) if OpenWrap, get the package you want into 'wraps'
4) for each project:
a) add reference to subject dll (manually if OpenWrap, NuGet will add for you)
b) fix compile error as needed
c) run tests
这听起来正确吗？
干杯，
贝里尔
I have a solution with multiple projects in it, so for example say 10 testing related projects have a dependency on nunit. Currently my solution structure includes folders for Tools and Lib, so maybe the full nunit download is in Tools and just the dll in Lib.
I suppose any package manager (NuGet and OpenWrap being two I'm looking at) needs to create it's own 'known' location for packages. So whereas the old fashioned way of package management, after manually updating my Lib folder, I know every project that had a dependency on nunit just got updated.
But if I update with a package manager, I need to visit each and every project to ensure it is updated and pointing at the same reference, yes? And some dll's may not be found (am thinking unHAddins right now) so you aren't completely liberated from manual package management. Meaning migration to the latest updates isn't done until each and every project is updated by the package manager.
So I'm wondering if my understanding is correct, what the best approach to incorporating package management into a decent sized solution is - for example:
0) add to source control: NuGet 'packages' folder or OpenWrap 'wraps' folder
1) pick a dll (start with one that you beleieve has minimal dependencies)
2) pick a project (ideally with minimal dependencies that might break)
3) if OpenWrap, get the package you want into 'wraps'
4) for each project:
a) add reference to subject dll (manually if OpenWrap, NuGet will add for you)
b) fix compile error as needed
c) run tests
Does that sound right?
Cheers,
Berryl
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
要回答您的问题，不，您不必使用 openwrap 执行任何操作，所有项目都会导入某个范围内的所有依赖项，因此更新适用于所有内容。
我无法回答其他包管理器的问题，但在 openwrap 中，您可以在源代码管理中添加 /wraps 文件夹，其中包含添加或更新它们时提取的包。该过程是首先从远程存储库添加包（或者如果没有可用的程序集，则从现有程序集创建一个包），然后手动从 /lib 中删除引用。在 OpenWrap 中，我们不会添加对 csproj 的引用，而是在构建时添加它们，因此如果 /lib 中已经存在依赖项，我们将不会添加它。这意味着您可以添加所有包，并逐个删除引用，每次都运行测试。
希望这只是一个暂时的问题，直到所有 dll 都可以作为包使用为止，这会很快发生。
To answer your questions, no you don't have to do anything with openwrap, all projects import all dependencies within a scope, so the update applies to everything.
I can't answer for the other package managers out there, but in openwrap, you'd add the /wraps folder in source control with the packages that got pulled when you added or updated them. The process would be to first add the package from a remote repository (or create one from your existing assemblies if there's not one available), and remove manually the references from /lib. In OpenWrap, we don't add the references to your csproj, we add them at build time, so if there's already a dependency in /lib, we won't add it. That means you can add all the packages, and remove the references one after the other, running your tests everytime.
Hopefully, this is a temporary problem until all dlls are available as packages, which will happen rather quickly.