Sign in to follow this  
wack

COM, 64 and 32 bit dll at the same time?

Recommended Posts

Hi,

I have a COM dll, currently a 32 bit dll. The problem arises when this component is used in 64 bit applications, as it says "Class not registered" when attempting to use it. This is especially problematic with .NET applications built for "Any CPU", because they will be 32 bit on a 32 bit OS and 64 bit on a 64 bit OS, causing people to become confused when it works fine on one machine, but not the other.

If I built a 64 bit version of the dll, would it be possible to have it registered while the 32 bit version is also registered, and automatically have the correct one loaded, depending on whether the calling process is 64 or 32 bit?

Share this post


Link to post
Share on other sites
Damn, I should know this as we solved it at work last year.
I think we ended up making it so that .NET would load the 32-bit version, thought I can't for the life of me remember what the change was. I might get back to you on this one.

Share this post


Link to post
Share on other sites
[quote]
If I built a 64 bit version of the dll, would it be possible to have it registered while the 32 bit version is also registered, and automatically have the correct one loaded, depending on whether the calling process is 64 or 32 bit?
[/quote]
Should be perfectly fine. There are two versions of HKEY_CLASSES_ROOT on 64 bit Windows, the registrations wouldn't overwrite each other. The 32-bit version is accessible under the HKCR\Wow6432Node\ key in regedit.

Then the calling app does CoCreateInstance or the .Net equivalent and the loading will hopefully be transparent.

Share this post


Link to post
Share on other sites
[quote name='iMalc' timestamp='1306611228' post='4816872']
Damn, I should know this as we solved it at work last year.
I think we ended up making it so that .NET would load the 32-bit version, thought I can't for the life of me remember what the change was. I might get back to you on this one.
[/quote]


Maybe you set the target CPU to "x86" instead of "Any CPU", that's what i have to tell users of this component to do, but it's almost getting annoying to get the same question from users :)

And i think it's not always a feasible option, they could, for instance be calling the component from an IIS server configured to run ASP.NET in 64 bit mode, in which case they have to switch IIS to 32 bit mode, and that might not work if they have other apps or components called from IIS that require 64 bit mode. Luckily, this hasn't happened yet, but i'm starting to feel it's just a matter of time.

There are a few other options i have considered, such as [url="http://msdn.microsoft.com/en-us/library/ms695225(v=VS.85).aspx"]Dll Surrogate[/url], which would supposedly turn my dll into an outproc server (for those, it doesn't matter what type the calling process is), but I'm not too keen on all the costly marshalling that would be involved...

[quote name='adeyblue' timestamp='1306616686' post='4816913']
[quote]
If I built a 64 bit version of the dll, would it be possible to have it registered while the 32 bit version is also registered, and automatically have the correct one loaded, depending on whether the calling process is 64 or 32 bit?
[/quote]
Should be perfectly fine. There are two versions of HKEY_CLASSES_ROOT on 64 bit Windows, the registrations wouldn't overwrite each other. The 32-bit version is accessible under the HKCR\Wow6432Node\ key in regedit.

Then the calling app does CoCreateInstance or the .Net equivalent and the loading will hopefully be transparent.
[/quote]

This does sound good, I guess I'll just have to give it a shot. :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this