So, let start with something simple (which I am slightly embarrassed I didn’t know earlier)…
Until a recent attempt to port a 32bit application to 64bit forced me to think about it, I have never really appreciated how the assembly references in a C# project are actually used while building an application. I am always assumed that the assembly referenced at build time was the one that had to be used at runtime. This is not the case.
My original question was: in a Visual Studio project, however do I force the assembly references to switch between 32bit and 64bit versions of a DLL while compiling? It turns out I don’t need to; you can compile a 64bit application using references to 32bit DLLs, assuming the name/version/signing does not change when the bitness changes.
I was originally led astray after someone showed me some edits you can make to the csproj file that will change the reference hint paths at build time depending on the environment settings. This seemed like a neat hack, however I now realise that it is unnecessary: during compilation, the only information stored in the new assemblies is the meta-data regarding the reference assemblies; there is no reference to bitness. This means that, as long as you deploy the correct third party assemblies with your application at runtime, you don’t need to worry about the bitness at compile time.
Doh.