Exception raised in WPF app, when referencing C++/CLI code

Question

0.00/5 (No votes)

See more:

Hi,

I am working with a large codebase written in C++ & MFC as well as other API's, and am trying create a WPF application (C#) which uses this C++ code. I don't want to rewrite everything in .NET. I am creating a C++/CLI interface that wraps some of the C++ code. The DLL produced from this is added as a reference to my C# project. It builds fine but I receive the following exception when running this code:

"A first chance exception of type System.Windows.Markup.XamlParseException occurred in PresentationFramework.dll. Additional information: Cannot create instance of Window1 defined in assembly ..., Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. Exception has been thrown by the target of an invocation. Error in markup file 'Window1.xaml' Line 1 Position 9."

How can I even debug this?

Below is the C# code:

// C#

C#

using System;
using IMyCLIInterface;
namespace CsharpNamespace
{
    public partial class Window1 : Window
    {
       public Window1()
        {
            InitializeComponent();
            // If I comment out the next two lines, then the exception does not occur
            IMyCLIInterface.theClass c = new IMyCLIInterface.theClass();
            c.TestInterface();
           // If instead of the above two lines I simply put the following line, then the exception does not occur 
           // IMyCLIInterface.theClass c = null
        }
    }
}

And below is the C++ code:

// H file

C#

#pragma once
namespace IMyCLIInterface
{
    public ref class theClass
    {
    public:
        theClass(void)
        {;}
        void TestInterface();
    };
}

// CPP file

C#

#include "StdAfx.h"
#include "IMyCLIInterface.h"

using namespace IMyCLIInterface;

[System::STAThreadAttribute]
void theClass::TestInterface()
{
    //nothing in here for now, but intending to call native C++ code in here
}

Posted 17-Oct-10 9:48am

Arivanna

Updated 17-Oct-10 14:12pm

v5

Add a Solution

8 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

ARopo · Answer 1 · 2010-10-18T01:00:00

I've had simular issues to this in the past, it is nearly always to do with the loading of assemblies and dependant unmanaged dlls. MFC dlls can cause problems when CWinApp::InitInstance is called to early. In .net not all dlls are loaded upfront, the first time you access a class then the underlying dlls will be loaded.

Try creating your c++/.net class later e.g. on Window1 load or just to test, create from a button click event

Nish Nishant · Answer 2 · 2010-10-18T03:48:00

Solution 2

The most likely reason is that the WPF application cannot find the C++/CLI assembly. Copy the DLL to the same folder as the WPF exe and you should see this error go away.

Posted 18-Oct-10 3:48am

Nish Nishant

Arivanna · Answer 3 · 2010-10-18T10:41:00

Thanks for your responses. I have updated my C# project so that it produces a class library DLL instead of an exe. This is placed in a folder containing the executable which will use this DLL. The DLL produced by my native interface class is also placed in the same folder. When I load the C# Dll, it loads fine. However when I run a command which uses my native C++ DLL, I recieve an exception:

System.IO.FileLoadException: Could not load file or assembly IMyCLIInterface, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null; or one of its dependencies. Exception from HRESULT: 0xE0434F4D
File name: IMyCLIInterface, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null; ---> System.Runtime.InteropServices.COMException (0xE0434F4D): Exception from HRESULT: 0xE0434F4D at MyDLL.Window1..ctor()

I have tried DependencyWalker to determine the problem and the required DLL's appear to be in the same folder. Is there no easier way to find which dependency exactly is causing the problem?

If I hit continue and run that same command again, I then receive another error:
Attempt to use MSIL code from this assembly during native code initialization. This indicates a bug in your application. It is most likely the result of calling an MSIL-compiled (/clr) function from a native constructor or from DllMain.

I get the impression that using mixed assemblies is not trivial, and that migrating to .NET would be the faster (though not ideal) way to go.

Nish Nishant · Answer 4 · 2010-10-18T10:48:00

Solution 4

Does the native DLL have other dependencies? If so, those need to be in the standard search path too (or in the same folder as the exe/other dlls).

Posted 18-Oct-10 10:48am

Nish Nishant

Arivanna · Answer 5 · 2010-10-18T10:57:00

Hi Nishant thank you for your response. Yes using Dependency Walker it appears to have several dependencies, however these are either located in my system32 folder (which is part of the standard search path), otherwise they are available in that same folder as the .NET dll.

Are there efficient ways of debugging this?

Arivanna · Answer 6 · 2010-10-19T07:56:00

I have enabled breaks on CLR exceptions in Debug mode and now I receive the following error, which must be why the DLL cannot be loaded:

MSIL

Managed Debugging Assistant 'LoaderLock' has detected a problem in '----.exe'.
Additional Information: DLL 'IMyCLIInterface.dll' is attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

However I do not even have a DLLMain or entry point, I don't see where this could be happening? How can I debug this effeciently, given that I am dealing with a large native C++ code base (which links against other C++ static libs, and API's)?

Rolf Kristensen · Answer 7 · 2010-10-21T11:56:00

I would probably make a simple example that works, and then slowly port the legacy code into the project.

If performance is not important, then I would look into compiling the entire C++ codebase using the /CLR compiler switch. This will give a managed dll, that should be easier to use from WPF.

When compiling the C++ codebase make sure that all included projects (and static libraries) are compiled with the same runtime library (must be "Multi-Threaded DLL") and "Use MFC in shared library".

Rolf Kristensen · Answer 8 · 2010-10-21T11:59:00

Solution 8

You can also approach it the other way around by compiling the WPF as a COM+ dll, and then load it as a custom control in the MFC application.

Posted 21-Oct-10 11:59am

Rolf Kristensen

Exception raised in WPF app, when referencing C++/CLI code

8 solutions

Solution 1

Solution 2

Solution 3

Solution 4

Solution 5

Solution 6

Solution 7

Solution 8

Add your solution here

Preview 0