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 gets latest?
+1
A:
You want to do this as part of your build, right?
Write a pre-build step to copy the referenced DLL from a permanent position in your source tree to the local project. Use the $(ConfigurationName) or $(PlatformName) macro to select which version of the unmanaged DLL actually gets copied. You just keep your DLLs in separate folders with names that match the configuration name or platform name.
Robert Lewis
2009-03-06 01:53:12
Actually, this is at design time. We have the solution for the build process in place, but a few of the devs anctually compile in Debug | x64.
PeteK
2009-03-11 16:21:36
+1
A:
It is rather odd that the devs with the x64 machine willingly run the 64-bit version. Visual Studio doesn't support Edit+Continue in x64 mode, that's quite a loss. The workaround for that is simple, set the Platform Target to x86. Automagically also solving your unmanaged DLL problem.
Hans Passant
2009-03-06 13:37:10
It is odd, and I will discuss it with the three black sheep, but it would be even better if there were a solution to this. I guess it's a pretty fringe case, but I'll keep looking.
PeteK
2009-03-11 16:20:50
A:
There is another solution that involves editing your code a little. It is described in the answer from Milan Gardian to this question.
Basically it involves writing your own assembly reference handler to determine which assembly to load at runtime, provided that you have access to both (32- and 64-bit) versions of the assembly. I have just implemented this solution my self, and it works like a charm.
My situation is this:
I'm developing a .NET program targeted for "Any CPU" on Windows 7 64-bit. I have added the 32-bit assembly reference, and set Copy Local to false. I use post-build events to copy the 32- and the 64-bit assembly to the output folder, and I make sure to give the 32-bit assembly a different name than in the reference. This is because I want to force my custom assembly resolver to kick in and do its thing, due to the fact that .NETs default assembly resolver can't resolve the reference. At runtime the correct assembly is loaded, and at compile time i get no errors. It should be noted that I haven't had the time to actually confirm that this is now working on 32-bit OS, but I don't see any reason why it shouldn't work.
Sub-Star
2009-09-18 20:31:32