0

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

Berryl
  • 12,471
  • 22
  • 98
  • 182

1 Answers1

1

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.

SerialSeb
  • 6,701
  • 24
  • 28
  • Thanks, Sebastion - I updated my cheesy process flow accordingly. – Berryl Feb 16 '11 at 19:01
  • hold on, somethings wrong here, cause I can't build my project within VS that is trying to use log4net. It's because there is no reference in csproj. Also I could not find a single tutorial that would explain this issue, your introduction simply skips this step - I mean the part "oh and here you can see that VS no longer complains about log4net - no more red color". In my project red color stays and I can't compile. – Piotr Owsiak Apr 15 '11 at 23:53
  • Ok, I can see, which is obvious to me now, that the problem was that I had not use fully qualified type names which caused the compilation problem. However I see 2 issues: 1) still my R# complains about not understanding anything from log4net assembly (in red) 2) I don't want to fully qualify all types from libraries managed by OpenWrap – Piotr Owsiak Apr 16 '11 at 00:03
  • As for the second issue I know I can manually write my usings, but I don't want to cause thats R#'s job. – Piotr Owsiak Apr 16 '11 at 00:06