Simple Answer
For best compatibility, ASCOM drivers and applications developed with .NET languages should target ‘Any CPU’.
Explanation
Some background facts.
- 32-bit processes can run on a 64-bit system.
- 32-bit processes can call into 64-bit code.
- 64-bit processes cannot call into 32-bit code.
- .NET assemblies compiled as ‘x86’ can only run in 32-bit processes.
- .NET assemblies compiled as ‘x64’ can only run in 64-bit processes.
- .NET assemblies compiled as ‘Any CPU’ are JIT-compiled into the ‘bitness’ of their host process (not necessarily the machine architecture).
- Visual Studio (including 2010) is a 32-bit process. It can debug 64-bit applications but with some limitations.
Truth Table: Where can an assembly execute?
The only scenario that guarantees 100% compatibility is: ‘Any CPU’.
There may be a temptation to think that compiling an assembly (ASCOM driver) as ‘x86’ means that it can run on any system. In fact, most of the time that will be true, but as soon as there is a 64-bit host process then the driver will fail.
On 64-bit systems, by default, 64-bit host processes include: Windows Scripting Host (VBScript/JScript). To see this in action, compile your driver for 'x86' then try to script it on a 64-bit system. Your driver will fail to load.
Development and Debugging in Visual Studio
The above advice notwithstanding, during development you’ll face a different set of problems. Visual Studio is a 32-bit process so when it builds and registers your projects for COM Interop, it will do so as a 32-bit process. This means your driver will not operate correctly as a 64-bit driver on your development system. There are also some restrictions on debugging 64-bit processes, for example ‘edit and continue’ doesn’t work. I put this situation to Scott Guthrie and his recommendation was to develop and debug in 32-bit mode. He mentioned that in Visual Studio 2010 the same situation exists and they changed the default project settings to ‘x86’ for that very reason.
The solution I’ve used is to create multiple configurations in Visual Studio. My Debug configuration builds in ‘x86’ mode and my Release configuration builds in ‘Any CPU’ mode. There are lots of permutations but those would be the minimum.
LocalServer Based Drivers
Drivers based on the LocalServer pattern are COM out-of-process servers. They execute in their own process and not inside the process space of the client application. So, LocalServer drivers are in a different situation to 'normal' drivers. Because the driver is in a seperate process, COM must use an inter-process communication (IPC) mechanism that is not affected by the bit architecture of either process. So, for LocalServer based drivers, it may be safe to configure them as 'x86'. Some driver developers have reported success with this approach and it does seem to simplify the deployment issues somewhat, however, more data is needed from the field before this can be recommended as normal practice.
