NuGet packages folder

So yesterday I tweeted:

why doesn’t #NuGet allow me to specify where the ‘packages’ folder goes??

and @davidfowl from the team asked me a great question:

Why do you need that?

144 characters just ain’t enough so I figured a quick blog is the best way to answer.

I’ve been using NuGet for about 6 months or so and love the whole concept of picking what I want from a list and let it do the boring stuff (download, unzip, add references etc) is awesome, plus of course the uninstall works brilliantly.

One little thing concerned me but did not stop me from using it…after a while I noticed I had multiple ‘packages’ folders through my source.

Now what I have done for years with 3rd party libraries is put them into a ‘SharedComponents’ (or similarly named) directory which sits in my root Dev folder, easily accessible by all my projects. This means I have one place only where components are referenced. This means all of my projects have the same version, for me this is good (I know if you’re a big dev shop you may need different versions for different projects).

NuGet changed this, giving me a packages folder in ‘a few’ different places. This was not a problem until recently when I added Rx to a project using NuGet and then I started getting a weird ‘co-varient contravarient something’ error (I don’t remember the specifics of the error). The problem was that one of my shared projects was referencing a different (older) version of Rx (installed by NuGet) some time ago.

My fix was to go back to my ‘old school’ way of referencing the Rx .dlls, all projects pointing to the same dlls in the same folder. Worked immediately.

But that sucks. NuGet is a great concept and saves me plently of time, I should be able to and want to use NuGet but version issues is pretty much a show stopper for me, these problems usually surface as very obscure bugs that _can_ take alot of time to narrow down to the fact that there is a versioning problem.

So if I could specify where the ‘packages’ folder always ‘lives’ (ie override the default, which seems to be where the .sln file is?), then my versioning problem would no longer be a problem.

Another advantage is keeping source control of components to a minimum. With multiple ‘packages’ folders with multiple versions (often the same) of the same 3rd party components, all of these get stored in source control or the projects won’t build on a build box. Better to have one source….unless you have a compelling reason to keep multiple/different versions.

So for my usage it would be really helpful to be able to specify where the ‘packages’ folder lives 🙂 Anyone else agree/disagree…with reason?

  1. There be dragons – unsupported functionality:

    • wallism
    • August 31st, 2011
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: