tags:

views:

173

answers:

1

I have a 32 bit COM component that is used mostly by ASP, we also have the 64 bit version.

The 64 bit version is functionally identical and it also uses the same ProgID (and as far as I know the same CLSID's etc).

Can I install/regsvr the 64 bit version on the same machine as the 32 bit version (obviously in a different folder) and have my existing 32 bit applications continue to use the 32 bit component, whilst my 64 bit applications consume the 64 bit version?

These are native code components written in C++ and not .NET.

+4  A: 

This should be possible.

On 64-bit windows, the registry and file system is redirected for 32-bit applications. Registration for the 32-bit COM dll's will be under a separate location in the registry (HKLM\Software\Wow6432Node\Classes), and your COM components should live in separate folders, 64-bit under Program Files and 32-bit under Program Files (x86). The registry/file redirection for 32-bit apps should make this work transparently.

It is possible that the component itself could prevent this - for instance, if it creates global resources that would wind up conflicting between the 32-bit and 64-bit versions.

This situation already exists on 64-bit Windows. On my 64-bit system I have:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID{8856F961-340A-11D0-A96B-00C04FD705A2}\InProcServer32\Default = C:\Windows\SysWow64\ieframe.dll

And

HKEY_CLASSES_ROOT\CLSID{8856F961-340A-11D0-A96B-00C04FD705A2}\InProcServer32\Default = C:\Windows\System32\ieframe.dll

32-bit and 64-bit version of WebBrowser control on the same system.

Michael
That's what I hoped might happen, but Reed seems to suggust otherwise. I can't try it just now because I don't have access to a 64 bit test environment I can clobber if it breaks something.
Kev
@Kev: this was my mistake. Michael is correct here.
Reed Copsey
I just found a machine I could test this on and it all works fine. :)
Kev