Developing for both 64-bit and 32-bit

Question

I've read a lot on the subject of converting 32-bit to 64-bit. I use a lot of vendor hardware, and have finally obtained both 64-bit and 32-bit drivers for each. Moving from 32 to 64 seems like it will be an easy transition.

The problem, however, is that we do not wish to "transition". We want to maintain both, side by side, without having to duplicate the codebase for each modification we perform. And by "we", I mean "I", since I'm the sole developer and it would effectively cut my productivity by a third to duplicate changes.

I understand that for a simple C# app, I can simply compile a version that will run regardless of architecture, and have been able to do it. However, I'm having a disconnect at figuring out how to handle the drivers and libraries I use. I think it'd be trivial to simply write 2 different installers, each installing the appropriate drivers, but how do I actually reference those DLLs in the application? If I reference the 32-bit drivers but install the 64-bit drivers, I get errors that it cannot find the proper libraries. Trying to reference both doesn't fix things, as one will always be missing.

How do I handle this properly? I'd like ideas on both the installation side (am I right about using 2 separate installers) as well as how to properly reference the DLLs to allow for either.

Answer 1

Can you just reference one generically named .dll, and have that DLL be 64-bit or 32-bit as installed by the installer? Also, if you can rely on the target file system being NTFS, you could symlink to the 32-bit or 64-bit DLL as needed.

Answer 2

The optimal solution is as Reinderien suggests: Let the installer handle it.

If, for some reason, you want to install both 32- and 64-bit DLLs and have your application work out which to load, the SetDllDirectory API function comes in handy. Your p/invoke DllImport attribute can use "SomeLib.dll" and you can use SetDllDirectory to point to .\Lib32 or .\Lib64 subdirectories. You would do this as soon as possible, probably first thing in Main.

Answer 3

Check out ScottHanselmans article "Back to Basics: 32-bit and 64-bit confusion around x86 and x64 and the .NET Framework and CLR".

He doesn't mention anything that specifically covers you installer dilemma but there might be some useful info for you.

One thing I can throw in: are you able to abstract out the drivers (or the code that works with the drivers) via Dependency Injection - just like you'd abstract out Data Access in a N-Tier app?

Answer 4

It's best practice to make two setups, thats why you'll have trouble finding info on a hybrid, as far as Microsoft goes, they say 2 setups, and 3rd party setup IDE like installshield endorse that policy.

In Installshield you would use release flags that you pass in command line to Installsheild when building the setup. You make 2 merge modules, one for 32 and one for 64 containing your drivers for each platform, when the setup builds, your release flag already assigned to each merge module allows to select 32bit if your building 32 and vice versa.

Btw, if your application runs on windows, it's very likely your customers will migrate faster than you expect, once your 64bit version is available. Last time I started maintaining a dual platform build, it was supposed to go on for years, and in the end we stopped building 32bit after only a few months.