locked
Dual Entry DLL (win32 and clr) RRS feed

  • Question

  • Hi,

    I am curious if it is possible to make a dual entry point dll, that has both Win32 and CLR entry point. If I create a win32 dll project and turn on CLR for some of the cpp files inside, will it have the assembly info needed for other .NET dlls to use it? what will be the output if I do so?

     

    Thursday, June 24, 2010 6:29 AM

Answers

  • Hello,

    Thanks ildjarn for your input. Yes, we still can export native functions if we compiler with /clr option. Actually C++\CLI is designed as the bridge of the native world and managed world, and the ouput is a combination of native assembly and MSIL assembly(that's why C++\CLI cannot be compiled to AnyCPU platform). Therefore, if we load that dll, the CLR will be started.  

    I think what Haojie means is load the DLL compiled with /clr without load CLR, the answer is no.

    Regards,
    Rong-Chun Zhang
    MSDN Subscriber Supportin Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com  


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    • Marked as answer by Haojie Zheng Thursday, July 1, 2010 12:51 AM
    Thursday, June 24, 2010 1:45 PM

All replies

  • Yes, it's possible, and it will work as you expect. I'm not sure what you mean by "what will be the output" though.
    Thursday, June 24, 2010 9:00 AM
  • Hello Haojie,

    Based on my experience, if you enable /clr compiler option for one cpp file in a project, the output will became a .net assembly. I would like you create two configurations for that project, one output a native dll, the other output a .NET assembly.

    Regards,
    Rong-Chun Zhang
    MSDN Subscriber Supportin Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com   


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Thursday, June 24, 2010 9:16 AM
  • A .Net assembly written in C++/CLI can export native functions, which can be used by native applications that know nothing of .Net. This is an easy way to expose .Net functionality to native applications (I think of this as reverse interop, as interop is normally used to expose native functionality to managed applications).

    However, there are some potential drawbacks when the native exports get called by a native application. E.g., the CLR will be loaded into the process using the .dll, but a process cannot host more than one version of the CLR at a time, so if that process uses any other .Net functionality, it must use the same CLR version as your .dll. Also, even if your .dll is unloaded before the process ends (with LoadLibrary/FreeLibrary), the process continues to host the CLR until process termination.

    Thursday, June 24, 2010 9:28 AM
  • Hello,

    Thanks ildjarn for your input. Yes, we still can export native functions if we compiler with /clr option. Actually C++\CLI is designed as the bridge of the native world and managed world, and the ouput is a combination of native assembly and MSIL assembly(that's why C++\CLI cannot be compiled to AnyCPU platform). Therefore, if we load that dll, the CLR will be started.  

    I think what Haojie means is load the DLL compiled with /clr without load CLR, the answer is no.

    Regards,
    Rong-Chun Zhang
    MSDN Subscriber Supportin Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com  


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    • Marked as answer by Haojie Zheng Thursday, July 1, 2010 12:51 AM
    Thursday, June 24, 2010 1:45 PM
  • Hello Haojie,

    Have you got any progress on this issue?

    Regards,
    Rong-Chun Zhang
    MSDN Subscriber Supportin Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com   

     


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, June 28, 2010 9:01 AM
  • Thanks, it seems to be working as what you said. Thanks alot for the answer!
    Thursday, July 1, 2010 2:17 AM