none
using 32/64 bit activex Control in .net app RRS feed

  • Question

  • Hi,
       Can any help me I have a 3rd party activex control that we embed in our .Net 4.0 application it comes in 32 and 64 bit version.  At present we compile the app to x86 and ship the controls 32 bit version only.  I would like to be able to compile the app as "any cpu" and dynamicly select the contols version based on Environment.Is64BitProcess.
     
    How do i do this?
    At pressent a lot of the code has be auto generated when i dragged the control on to a form.  What i need is to know how to hand craft the code.
    know i will need 2 Ax files (a 32 and a 64 bit) and 2 interop files (again 32 and 64)  for the control.


    Thursday, January 5, 2012 1:12 PM

All replies

  • In principle, I would have imagined that the 32 and 64-bit ActiveX controls use the exact same interfaces and the exact same GUID's.  This means that you need not 2 interops, but only one.  When running the .net application (any cpu) in a 64-bit environment, it should immediately pick up the 64-bit ActiveX because it will be accessing the system registry view for 64-bit, which is pointing to the 64-bit dll in the key HKLM\Software\Classes\CLSID\<GUID of the coclass>\InProcServer32, making the whole thing transparent.  At least it is what I would expect.  Is this not the case for you?
    Jose R. MCP
    • Edited by webJose Thursday, January 5, 2012 2:21 PM
    Thursday, January 5, 2012 2:20 PM
  • I have done a quick test.  by creating a windows form project and dragging the control on to the main form.  building the app as x86 and runing up on my 64 bit machine works fine.  However when i build and run as "any cpu" i get:

    "Could not load file or assembly 'Interop.CortonaVRMLClientLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format."

     

    I supect this is due to the autogenerated Ax and interop files are 32 bit.


    So the first question is how do i get round this?
    Thursday, January 5, 2012 4:20 PM
  • I think it may be difficult to embed 32-bit and 64-bit 3rd party assembly in a .NET application. Because if you build the application with AnyCPU option, it will run as 32-bit process on 32-bit  machine and as 64-bit process on 64-bit OS. CLR don't know which assembly should be loaded into current domain.

    I'm afraid that you need to build two separate application. One for 32-bit machine, add 32-bit version of 3rd party production and build application with X86 option. The other for 64-bit machine, add 64-bit version of the production and build application with X64 option.


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Tuesday, January 10, 2012 8:37 AM
  • Well, Interop DLL's are merely declarations of interfaces and GUID's, as far as I can tell.  So if you did the interop DLL yourself, you could make it so it targets any CPU.  Google up some documentation on what exactly is in an interop DLL for a COM object.  If you can manually replicate that information, you will be in charge and you should be able to compile the whole thing for Any CPU.
    Jose R. MCP
    Tuesday, January 10, 2012 1:55 PM
  • Have you registered both assemblies (regsvr32) on your 64 bit machine?

    If both controls use the same CLASSID (which is the only way I think this will work) then you will find two entries in your registry

    HKCR\CLSID\{???}

    and HKCR\Wow6432Node\CLSID\{???}

    They should be pointing to 2 different DLLs

    Tuesday, January 10, 2012 9:56 PM
  •  

    Hi Steven,

     

    I am writing to check the status of the issue on your side. Would you mind letting us know the result of the suggestions?

     

    If you have got answers, please remember to mark answer and close this thread.

    If not, any more concerns, please feel free to let us know.

     

    Have a nice day!


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Monday, January 16, 2012 5:02 AM