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 reference 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’).