Developing on both 32 bit and 64 bit processors, how should I structure my project to automatically reference the right dlls?

I am currently in a situation where I have both 32 bit and 64 bit developer machines working on my c# project. I have to reference a couple dlls that have both a 32 bit and a 64 bit version. Obviously, the 32 bit machines need to refe开发者_StackOverflowrence the 32 bit dll, and the 64 bit machines the 64 bit dll. The issue I am having is that every time a developer checks in some code, they also check in their dll references, so when someone on the other side pulls their code, it doesn't build, and they have to manually update their references back to what they should be. Then they check in, and the other developers have to manually fix their references, etc. etc. ad nauseum.

I don't imagine this is a new problem, but it is the first time I have run into it. Is there a common practice to have a project automatically reference the correct dll for the CPU? Or perhaps a way to have a 32 bit and 64 bit project, each with the correct references, and a way (possibly a command line tool or some outside that can be tied into a build) to tie them together so that when new items are added or removed to one, the other will also be updated?

The other option is to have every developer use the same virtualized development environment. If I go this route, can I virtualize a 64 bit system on 32 bit hardware, or do I have to go the other way, and virtualize 32 bit. This will be a SaaS product, so I only have to deploy for one processor, and I would prefer that to be 64 bit.

Here you find an example for how to change the assembly reference according to your target platform:

http://www.ryangerard.net/post/8768828095/how-to-change-visual-studio-assembly-references

(You have to change the .csproj files manually). And not to forget, on the 32 bit machines choose 'x86' as target platform, while on the 64 bit machines, choose 'x64').

I have a similar issue but my solution is a bit different. I simply have all the developers develop with the x86 DLLs.

So, the code is actually identical on all machines. Then, at run time (and for testing), I use a launcher app which will test the OS and move around the DLLs so that at runtime the proper DLLs are used. The logic in the launcher is quite simple. Something like:

If IntPtr.Size = 8 Then
  '-- Copy x64 DLLs into position
Else
  '-- Copy x86 DLLs into position
End If

Of course, when copying, you need to copy back so you can always switch between x64 and x86 (in the case of a portable application). However, if you're installing a non-portable application then there is no need for the launcher as this OS check can all be done inside the installer (so only the proper DLLs get installed).

You will need to edit your project file to use a non-specific version of the DLLs in question (otherwise this moving around logic will not do what you want it to).

I am going through a similar task. My solution was to use pre-buld events and specific resource folders. My 32bit reference dlls went into one folder, and the 64bit in another.

del "$(ProjectDir)\dlls*.dll" - delete all dlls from the common resource folder

xcopy "$(ProjectDir)\CommonResources" "$(ProjectDir)\dlls"/s /i /y - Copy common dlls into the resource folder

The following two commands copy the correct 32 or 64bit dlls into the resource folder

if $(PlatformName) == x64 (xcopy "$(ProjectDir)\dlls-64\My64Bit.dll" $(ProjectDir)\dlls/s /i /y)

if $(PlatformName) == x86 (xcopy "$(ProjectDir)\dlls-32\My32Bit.dll" $(ProjectDir)\dlls/s /i /y)

Using similar commands for the post build, I the required references to the output directory for packaging.