WPF throwing an exception parsing XAML that includes a Winforms User Control

Question

I have a WPF app that makes use of a Winforms User Control that I have created using C++/CLI. When my app goes to parse the XAML for my main window, it throws an exception. The information appears to be somewhat abbreviated, but it says:

A first chance exception of type 'System.Windows.Markup.XamlParseException' occurred in PresentationFramework.dll

Additional information:   is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)  Error in markup file 'OsgViewer;component/osgviewerwin.xaml' Line 1 Position 9.

I commented out my Winforms control in the XAML and everything loads fine. I figured maybe the constructor for my control is doing something bad, so I put a breakpoint in it, but the breakpoint does not appear to be enabled when I start to run the app, and is never hit, which I understand to mean the DLL containing that line is not loaded. Which would most likely cause an exception to be thrown when an object of a type in the DLL is instantiated - the body of the object's constructor couldn't be found.

I have done this successfully on a different project in the past, so I pulled in a different WinForms User Control from that app, and instantiated it in the XAML, and that all works fine.

So it's something in this DLL. I have a reference to the DLL in my WPF C# app, and when I load the DLL in Object Browser all the required classes and namespaces show up fine. The app compiles fine, the problem just shows up when parsing the XAML. Anybody seen something like this? Any ideas as to what could be causing this? Ideas for debugging it? Thanks!

<Window x:Class="OsgViewer.OsgViewerWin"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:int="clr-namespace:System.Windows.Forms.Integration;assembly=WindowsFormsIntegration"
    xmlns:myns="clr-namespace:MyGlobalNS.MyNS;assembly=MyAssembly"
...
        <int:WindowsFormsHost x:Name="m_Host">
         <myns:CMyClass  x:Name="m_MyClass" />
     </int:WindowsFormsHost>
...
</window>

Answer 1

I have experienced problems like that (but not with the exact same error message). It seems as if WPF cannot instantiate your Winforms User Control.

The challenge is to find out why. Here are my suggestions that you could try:

1. Check if you have enabled unmanaged debugging (in Project Properties -> Debug)
2. Find out if there are any dependencies your C++/CLI DLL where the Winforms control is implemented and if those dependencies cannot be resolved.
   In order to find out dependencies on native DLLs, you should use the tool Dependency Walker (depends.exe). .NET Reflector will only examine managed dependencies.
3. Comment out code of your Winforms User Control step by step and try again.
4. Use Gflags.exe to turn on Loader Snaps (cf. Debugging LoadLibrary Failures)

Answer 2

@EFrank: Thanks for your reply.

1) I have unmanaged debugging enabled

2) I have used RedGate's .NET Reflector, but it doesn't show any dependencies beyond the core Windows stuff - though I do know that it also depends on the OpenSceneGraph DLLs, which are native, and which do not show up in .NET Reflector for some reason. I'm afraid this is where the problem is stemming from.

3) I have tried this to no avail. I have even added a new UserControl-derived class that is basically empty to the DLL, and tried loading it, and I get the same result. Note that if I intentionally mispell the name of the UserControl in the XAML, I get an error at compile time, so at least at compile time, it is able to find the DLL and the class within it.

4) I will try this next. Thanks for the tip...

Answer 3

I also had this problem and all I had to do was go into the project properties>Security and click the This is a full trust application. I ran my project again and it worked!

Answer 4

Are you sure that you have the dll either in the system32 folder or in the same folder with the exe. I got the exactly same error message when running a WPF project built with CLI dll while the dll was located in the different folder.

mike

Answer 5

I've seen this problem when trying to use boost::threads. To support thread-local storage, boost::threads makes some Win32 API call that is incompatible with CLI applications. The problem gets triggered if you try to #include something from threads in CLI code.

Solution is to either avoid using boost::threads entirely or restrict its use to .cpp files in native code.