Problem using a 32 bits MFC ActiveX control on a 64 bits WinForms application.

Question

4.00/5 (1 vote)

See more:

VS2010

Hello everyone.

I am building a x64bits winform application and to complete my task, I need to reuse x32 MFX ActiveX control. When I try to paste the control on the WinForm, I get the following error message.

"Failed to import the ActiveX control. Please ensure it is properly registered"

When I open the property of the Ax.control, I see the following:
1. 'Copy Local' is set to false (when I use another control, it is set to true by default)
2. 'Path' is left blank where I normally should find the full file name to the interop dll.

I have searched on internet and I have discovered apparently this issue could be a Visual 2010 problem.
I have here the link to Hotfix information
http://support.microsoft.com/kb/2066987[^]

but how can I get the patch to cover that issue or do you have another alternative to cover that issue ?

Thank you very much in advance
Best regards.
MiQi.

Posted 19-Feb-13 4:26am

SuperMiQi

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2013-02-19T06:47:00

No in-proc components can be used in an application with different target instruction-set architecture, including ActiveX controls.
Please see: http://en.wikipedia.org/wiki/Instruction_set[^].

This is because every process can only work with executable modules of the same target architecture. If you try to dynamically link or load a module of different architecture (even supported by the present instance of OS), it may "work" but crash during run-time.

Of course, COM provides a way to work across this boundary, but only those working as separate processes, such as COM servers. They work with applications through IPC, which of course resolves the problem.

Some background: on a 64-OS, two target instruction-set architectures are supported: one of the "native" 64-bit architectures plus x86, which is available, because 64-bit CPUs support compatible 32-bit segments and x86 instruction set. On Windows, this is done via WoW64:
http://en.wikipedia.org/wiki/WOW64[^].

In this case, every process is started either under WoW64 or as a native 64-bit process (x86-64, Itanium) supported by CPU and the version of Windows. All other executable modules loaded in the process should be compiled for matching target architecture.

[EDIT #1]

The solution:

Compile your entry assembly of your solution with the target architecture "x86". All other assemblies used in your application can better be compiled with "Any CPU". When your entry assembly is loaded with all other assemblies, the resulting instruction set of the process (used by JIT) will be set to "x86", because it is defined by the combination of entry assembly setting and architectures actually supported by the OS. In this case, your process will be able to use x86 ActiveX control.

[EDIT #2]

Just in case, if this is not obvious at the moment:

You can have the case of using some assembly which uses 32-bit ActiveX control but that assembly is not uses as an entry assembly. I would advise to compile it to the target "x86" as well, because, if it always uses 32-bit control, there are no cases when it can use different target instruction-set architecture.

—SA