package managers, project structure and migration

I have a solution with multiple projects in it, so for example say 10 testing related projects have a dependency on nunit. Currently m开发者_运维知识库y 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

---

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.