views:

482

answers:

3

I would like to know how .NET teams out there are handling assembly reference paths when not everybody can immediately upgrade to a x64 operating system. The key issue right now is x64 versions of Windows will plant 32-bit installations into C:\Program Files (x86)\ instead of the regular C:\Program Files. This means many extra components and frameworks from 3rd parties end up in C:\Program Files (x86).

So when one downloads source projects created/modified in a x86 workstation onto a x64 workstation, there is some modification work required to get the reference paths correct. Quite typically, x64 users may save the modification and commit their "preferences" back into the version control repository, breaking the rhythm of the x86 users.

What are some good approaches to maintain harmony in a varied team?

+2  A: 

Either install the assemblies in the GAC on each machine, or have a special LIB folder under your solution root that contains all your 3rd party assemblies. The LIB folder is what I've used for the last few years myself. I even put the assemblies in source control so other/new developers get them without having to think about it.

sliderhouserules
+4  A: 

Adding 3rd party assemblies to a lib directory also goes a long way to ensuring that everyone on the team is using exactly the same version, rather than what was the latest version when they built their dev machine. It's too easy to get out of sync if you don't have them checked into a common location in source control.

briangraf
+1  A: 

This is more of a follow-on question than an answer, but I thought this group might know.

What do we do if we have some devs working on 64 bit machines and some on 32 bit machines, but we need to reference unmanaged assemblies that need to be in x86 for half the team and x64 for the other half? Is there a solution besides manually updating the references every time someone on a 64 bit rig get latest?

PeteK