none
C#, C++ Interop questions RRS feed

  • Question

  • Hello all,

    I have been experimenting with C# and C++ interop in .NET due to an upcoming project which requires that I output data in a format that matches an existing ( but changing ) set of header files.  So far things have gone pretty well and I hit 'hello world': I have data written by a C# app using a managed C++ DLL, which is then read by a Win32 C++ app ( both apps use the same data layout in a common library ).

    This is all great, but I do have a couple questions that I am hoping somebody here might be able to answer:

    1) I have heard that the managed-to-unmanaged transition is very slow, but I'm still not sure exactly where that occurs.  I am assuming that when calling functions in Managed C++ from C#, that the transition is not occurring.  Does it only occur when I actually call functions defined in a native library?  If I merely use header files from an unmanaged library to structure data, are any managed-to-unmanaged transitions occurring at all?

    2) I have tried calling various functions from my native library ( and they seem fine ), but I'm kind of befuddled as to where the code ends up.  Typically I am accustomed to adding libraries to the "Input" section of the C++ Linker of the application project.  But for this test, I added a Project Dependency on my native library in my "wrapper" managed library, and all of the sudden it just works.  I can see the .lib file in the Debug output folder, but not in the local output folders of either my managed library or my C# application.  Where does this code end up?  Is it linked directly into the managed .DLL somehow?

    3) When debugging my C# app, I am unable to step through code that takes place inside the native library.  I can step through all the managed C++, but as soon as I attempt a native function call, it skips over.  If I switch to disassembly, the native function call just appears as a "call 0x[number]" instruction, and I cannot follow it.  Perhaps this has something to do with missing symbols, since I don't see a .PDB file for the native lib in the common output folder.  Does anybody know what I might have to configure to allow me to debug the native code?

    Thanks very much for any help!

    Friday, June 25, 2010 7:06 PM

Answers

  • 1) I can't say I'm sure, but I think that at least all code inside the managed class is compiled to IL, so calling umanaged functions will have the transitions.

    2) Yes a DLL (and EXE) can contain native (unmanaged) code as well as managed code. So yes the lib ends up inside the DLL.

    3) This is an option inside the project options, go to debug tab and select 'Enable unmanaged code debuging'  (vs2010), but I'm sure that a similar option is there in vs2005. (I just it there, also I think it will disable the edit and continue possibility; at least in vs2005) 

     

    • Marked as answer by jujumbura Monday, June 28, 2010 2:10 PM
    Saturday, June 26, 2010 7:35 AM

All replies

  • 1) I can't say I'm sure, but I think that at least all code inside the managed class is compiled to IL, so calling umanaged functions will have the transitions.

    2) Yes a DLL (and EXE) can contain native (unmanaged) code as well as managed code. So yes the lib ends up inside the DLL.

    3) This is an option inside the project options, go to debug tab and select 'Enable unmanaged code debuging'  (vs2010), but I'm sure that a similar option is there in vs2005. (I just it there, also I think it will disable the edit and continue possibility; at least in vs2005) 

     

    • Marked as answer by jujumbura Monday, June 28, 2010 2:10 PM
    Saturday, June 26, 2010 7:35 AM
  • 1) I don't know. The question might be too general.

    2) You don't specify whether the lib file is for a static or a dynamic library. Your description of libraries indicate that you are familiar with static libraries, which are not sued very much and I am nearly certain that managed code cannot use static libraries at all. There are also dynamic libraries and the executable portion of them are DLLs. Have you heard of DLLs? There are many types of DLLs and many of them are COM objects or ActiveX and many others. One thig they all have in common are Type Libraries. A type library makes a DLL useful from any language that knows how to use type libraries. For .Net, the interaction is more advanced than COM and ActiveX. You can add a reference to a COM object or to a .Net library and when you do, the type library and other stuff can be used to determine how to call somethinjg and even how to find it during execution.

    3) I don't know but the previous post is probably either the answer or points in the right direction.



    Sam Hobbs; see my SimpleSamples.Info
    Sunday, June 27, 2010 10:56 AM
  • 2) Yes a DLL (and EXE) can contain native (unmanaged) code as well as managed code. So yes the lib ends up inside the DLL.


    Maybe I misunderstand what you are saying, but a lib is never in a DLL. A lib file is used by the link editor but a lib file is not used during execution. The DLL is used during execution but never by the link editor. The lib file describes the contents of the DLL but a DLL can be called explicitly during execution without a lib file and without implicit linking by the linhk editor.

    Unless it is a DLL that is being created; but even then, the above applies to all libs/DLLs used by the DLL being created.



    Sam Hobbs; see my SimpleSamples.Info
    Sunday, June 27, 2010 11:03 AM
  • 2) Yes a DLL (and EXE) can contain native (unmanaged) code as well as managed code. So yes the lib ends up inside the DLL.


    Maybe I misunderstand what you are saying, but a lib is never in a DLL. A lib file is used by the link editor but a lib file is not used during execution. The DLL is used during execution but never by the link editor. The lib file describes the contents of the DLL but a DLL can be called explicitly during execution without a lib file and without implicit linking by the linhk editor.

    Unless it is a DLL that is being created; but even then, the above applies to all libs/DLLs used by the DLL being created.



    Sam Hobbs; see my SimpleSamples.Info

    Based on the following comment of OP:

    "I have tried calling various functions from my native library ( and they seem fine ), but I'm kind of befuddled as to where the code ends up"

    Based on this I assumed it is jut a native library with code inside, not a wrapper for DLL entries.

    Again with C++ you can combine native and managed code into one DLL (I have done this my self so I'm really sure about that). So the linker will definitively include the native code from the lib into the resulting DLL.

    Even if you look with IL disassembler against such a DLL you get alot of strange kind of static methods that aren't apart of a class looking like this:

    .method public static pinvokeimpl(/* No map */)
            void modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl)
            SimMain(uint8 A_0) native unmanaged preservesig
    {
      .custom instance void [mscorlib]System.Security.SuppressUnmanagedCodeSecurityAttribute::.ctor() = ( 01 00 00 00 )
      // Embedded native code
      // Disassembly of native methods is not supported.
      //  Managed TargetRVA = 0x00006B50
    } // end of method 'Global Functions'::SimMain

    Sunday, June 27, 2010 2:32 PM
  • Based on this I assumed it is jut a native library with code inside, not a wrapper for DLL entries.

    There are two types of lib files; static and dynamic. I assume that when you say "wrapper for DLL entries" you mean that the lib file is for a DLL. So I assume that "native library" means static library. A static library contains code, and there is no DLL associated with it so the lib file is not in the DLL.

    Before Windows, the DOS link editor only created static libraries. A lib file was only for static modules. A static library is just a collection of obj files; a lib file is not much different from putting all obj files into a directory. The link editor would copy each obj file into each executable that uses it, which means that modifying a library function requires relinking all executables that use it. So for Windows, a lib file looks a lot like a static library except the code is stored separately and modifying a library function requires relinking only the DLL.



    Sam Hobbs; see my SimpleSamples.Info
    Sunday, June 27, 2010 7:17 PM
  • Hi,

       Thanks for your post.

       @1. I am not quite sure about your scenario. But if you are just marshalling data, there's no such transition.

       @2. If the native library you are calling is plain Win32 DLL, you are probably using the DLLImport attribute to do the P/Invoke. This attribute helps to loacate the DLL and find the proper exported method. If the native library you are calling is COM DLL, there're some interop assemblies that help you use the COM component transparently. These interop assemblies could be generated by tlbimp.exe or auto-generated by the Visual Studio when adding reference to a COM library.

         Please take a look at the following articles:

        1. Calling Win32 DLLs in C# with P/Invoke

        2. Introduction to COM Interop

        @3. Please enable "Enable unmanaged code debuggin" in your "project properties->Debug".


    Please mark the right answer at right time.
    Thanks,
    Sam
    • Edited by SamAgain Monday, June 28, 2010 10:02 AM refine
    Monday, June 28, 2010 10:01 AM
  • Thanks much guys! 

    And to clarify ( since it sounds like there was some question about it ), the "native lib" I am referring to is a static, unmanaged C++ library.  This code is called by my "wrapper" lib, which is a managed C++ DLL.  It sounds as though the code from the static library is definitely ending up inside that managed DLL from your responses.

     

    Monday, June 28, 2010 2:15 PM