Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: MFC COM NET WinForm , +
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 5:26am

1 solution

Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

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
  Permalink  
v3
Comments
SuperMiQi at 20-Feb-13 3:36am
   
Hello Sergey,
 
Thank you for your quick answer.
Could you please tell me what you should advise me to cover that issue? I need to place a x32 bits ActiveX control on a WinForm x64bits application. I do not have a x64bits version of the activex control I am trying to use.
 
Thank you very much in advance.
Best regards.
MiQi
Sergey Alexandrovich Kryukov at 20-Feb-13 11:52am
   
I think this is explained in [EDIT]. You should make your application 32-bit. Make its target platform x86. There is no other way.
Or create some separate x86 application to use the control, change architecture... I'm not sure if the control worth such effort...
—SA

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

  Print Answers RSS
0 OriginalGriff 350
1 Jochen Arndt 190
2 Richard MacCutchan 135
3 Sergey Alexandrovich Kryukov 130
4 DamithSL 105
0 OriginalGriff 6,045
1 DamithSL 4,601
2 Maciej Los 4,087
3 Kornfeld Eliyahu Peter 3,480
4 Sergey Alexandrovich Kryukov 3,310


Advertise | Privacy | Mobile
Web02 | 2.8.141220.1 | Last Updated 19 Feb 2013
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100