Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Loading .Net DLL in MFC application problem

Loading .Net DLL in MFC application problem

Scheduled Pinned Locked Moved C / C++ / MFC
c++helpcsharpdebugging
10 Posts 3 Posters 2 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • W Offline
    W Offline
    Wolfram Steinke
    wrote on last edited by
    #1

    I have been given a .NET Dll which I have to intergrate into and MFC solution. It sort of worked when I added it to Microsoft sample MFC04.exe sample, and imported it into one of it's Dlls. It gave a problem with passing strings to the MFC code but that should be easy to overcome. Creating a new project in the existing solution with the same settings first gave build error with unresolved external (the lib file never was built). Finally it builds but at runtime I get this: Debugger:: An unhandled non-continuable exception was thrown during process load The program '[2436] AppMgr.exe: Native' has exited with code -1073741511 (0xc0000139). Any assistance, suggestions to get round this would be most welcome.

    Happy programming!!

    P M 2 Replies Last reply
    0
    • W Wolfram Steinke

      I have been given a .NET Dll which I have to intergrate into and MFC solution. It sort of worked when I added it to Microsoft sample MFC04.exe sample, and imported it into one of it's Dlls. It gave a problem with passing strings to the MFC code but that should be easy to overcome. Creating a new project in the existing solution with the same settings first gave build error with unresolved external (the lib file never was built). Finally it builds but at runtime I get this: Debugger:: An unhandled non-continuable exception was thrown during process load The program '[2436] AppMgr.exe: Native' has exited with code -1073741511 (0xc0000139). Any assistance, suggestions to get round this would be most welcome.

      Happy programming!!

      P Offline
      P Offline
      Prasann Mayekar
      wrote on last edited by
      #2

      do u use #using using namespace and then compiling with clr option? calling .net dll from mfc dll has a mixed dll loading problem. but works if u use in a mfc app. Prasann

      P 1 Reply Last reply
      0
      • P Prasann Mayekar

        do u use #using using namespace and then compiling with clr option? calling .net dll from mfc dll has a mixed dll loading problem. but works if u use in a mfc app. Prasann

        P Offline
        P Offline
        Prasann Mayekar
        wrote on last edited by
        #3

        i mean #using dllname using namespace dllname

        1 Reply Last reply
        0
        • W Wolfram Steinke

          I have been given a .NET Dll which I have to intergrate into and MFC solution. It sort of worked when I added it to Microsoft sample MFC04.exe sample, and imported it into one of it's Dlls. It gave a problem with passing strings to the MFC code but that should be easy to overcome. Creating a new project in the existing solution with the same settings first gave build error with unresolved external (the lib file never was built). Finally it builds but at runtime I get this: Debugger:: An unhandled non-continuable exception was thrown during process load The program '[2436] AppMgr.exe: Native' has exited with code -1073741511 (0xc0000139). Any assistance, suggestions to get round this would be most welcome.

          Happy programming!!

          M Offline
          M Offline
          Mark Salsbery
          wrote on last edited by
          #4

          What is the lib file you refer to? Dynamically linking a .NET assembly has nothing to do with a lib file. Mark

          Mark Salsbery Microsoft MVP - Visual C++ :java:

          W 1 Reply Last reply
          0
          • M Mark Salsbery

            What is the lib file you refer to? Dynamically linking a .NET assembly has nothing to do with a lib file. Mark

            Mark Salsbery Microsoft MVP - Visual C++ :java:

            W Offline
            W Offline
            Wolfram Steinke
            wrote on last edited by
            #5

            That's interesting, cause the Microsoft example generates a lib for ".NET/MFC interface" Dll and links with it. The interface Dll uses the namespace for the .NET, yes, and that part works when I add it to the Microsoft sample. That Dll (Which is an MCF extension) then exports a C/C++ function which accesses the .NET dll. The error I'm getting now seems to be to with initialization when the dll is being loaded. It is trying to initialize both the managed and unmanaged code at the same time, and this is apparently a no-no. How can I get around this? It's much work to work to rewrite the umpteen other files in the solution.

            Happy programming!!

            M 1 Reply Last reply
            0
            • W Wolfram Steinke

              That's interesting, cause the Microsoft example generates a lib for ".NET/MFC interface" Dll and links with it. The interface Dll uses the namespace for the .NET, yes, and that part works when I add it to the Microsoft sample. That Dll (Which is an MCF extension) then exports a C/C++ function which accesses the .NET dll. The error I'm getting now seems to be to with initialization when the dll is being loaded. It is trying to initialize both the managed and unmanaged code at the same time, and this is apparently a no-no. How can I get around this? It's much work to work to rewrite the umpteen other files in the solution.

              Happy programming!!

              M Offline
              M Offline
              Mark Salsbery
              wrote on last edited by
              #6

              So it's a mixed-mode DLL, not a pure .NET DLL? Or is there another DLL involved between a .NET assembly and the MFC app? Mark

              Mark Salsbery Microsoft MVP - Visual C++ :java:

              W 1 Reply Last reply
              0
              • M Mark Salsbery

                So it's a mixed-mode DLL, not a pure .NET DLL? Or is there another DLL involved between a .NET assembly and the MFC app? Mark

                Mark Salsbery Microsoft MVP - Visual C++ :java:

                W Offline
                W Offline
                Wolfram Steinke
                wrote on last edited by
                #7

                Yes it's the mixed mode dll I'm getting something wrong in. No there is an MFC dll accesing the Mixed mode dll which in turn accesses the .NET assembly.

                Happy programming!!

                M W 2 Replies Last reply
                0
                • W Wolfram Steinke

                  Yes it's the mixed mode dll I'm getting something wrong in. No there is an MFC dll accesing the Mixed mode dll which in turn accesses the .NET assembly.

                  Happy programming!!

                  M Offline
                  M Offline
                  Mark Salsbery
                  wrote on last edited by
                  #8

                  Ok, I think I'm following now :) I would first make sure that you're following all the rules for an MFC extension DLL, as explained here: Extension DLLs[^] Initializing Extension DLLs[^] You should be able to link the app to the extension DLL (both the static link to the lib file at build time and the dynamic link at runtime) with no errors. Once you have that, the .NET DLL should be much simpler, since that linking is done by the assembly loader. If you still have the problem, it could be a loader-lock issue. Are you making any calls besides the required MFC initialization (as described in the links above) in your extension DLLs DllMain()?  If so, I would comment those out and test - that's where most DLL load problems occur. Global/static variables can be a problem as well. That's all I can think of off hand.  If you still get the error, can you post the contents of your debugger output window? Mark

                  Mark Salsbery Microsoft MVP - Visual C++ :java:

                  W 1 Reply Last reply
                  0
                  • M Mark Salsbery

                    Ok, I think I'm following now :) I would first make sure that you're following all the rules for an MFC extension DLL, as explained here: Extension DLLs[^] Initializing Extension DLLs[^] You should be able to link the app to the extension DLL (both the static link to the lib file at build time and the dynamic link at runtime) with no errors. Once you have that, the .NET DLL should be much simpler, since that linking is done by the assembly loader. If you still have the problem, it could be a loader-lock issue. Are you making any calls besides the required MFC initialization (as described in the links above) in your extension DLLs DllMain()?  If so, I would comment those out and test - that's where most DLL load problems occur. Global/static variables can be a problem as well. That's all I can think of off hand.  If you still get the error, can you post the contents of your debugger output window? Mark

                    Mark Salsbery Microsoft MVP - Visual C++ :java:

                    W Offline
                    W Offline
                    Wolfram Steinke
                    wrote on last edited by
                    #9

                    Something else I have observed that confuses me is when I select the mixed mode dll as a dependency in the MFC dll it's lib is automatically added to the linker command line. However once I selected /clr on the mixed mode dll that command line entry is automatically removed and causes unresolved externals. In the MS sample this does not seem to be case. I'm therefore thinking that my problems are to do with compiler/linker settings. If I start with the mixed mode dll as a pure MFC extension it works fine both implicit and explicitly linked at runtime. as soon as I add the /clr flag the problems start, before I even add the .NET dll to the references.

                    Happy programming!!

                    1 Reply Last reply
                    0
                    • W Wolfram Steinke

                      Yes it's the mixed mode dll I'm getting something wrong in. No there is an MFC dll accesing the Mixed mode dll which in turn accesses the .NET assembly.

                      Happy programming!!

                      W Offline
                      W Offline
                      Wolfram Steinke
                      wrote on last edited by
                      #10

                      Now that I have much finally building and running correctly, can you point me to an article or make a suggestion on how I can get error information when the .NET code throws an exception. try { CallToDotNetCode(); } catch(...) { // Do something here } This works fine in as much as catching the exception and I can return a value to indicate something has gone wrong. However I would like to extract the reason for the exception. If I put any sort of parameter into catch it stops working, so there must be another way of doing this which works reliably.

                      Happy programming!!

                      1 Reply Last reply
                      0
                      Reply
                      • Reply as topic
                      Log in to reply
                      • Oldest to Newest
                      • Newest to Oldest
                      • Most Votes


                      • Login

                      • Don't have an account? Register

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • World
                      • Users
                      • Groups