2008-10-22 16 views
7

Tengo una aplicación WPF que hace uso de un control de usuario de Winforms que he creado usando C++/CLI. Cuando mi aplicación va a analizar el XAML para mi ventana principal, arroja una excepción. La información parece ser algo abreviada, pero dice:WPF lanzando una excepción que analiza XAML que incluye un control de usuario de Winforms

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. 

me comentó mi control de Windows Forms en el XAML y todo carga finos. Pensé que tal vez el constructor de mi control estaba haciendo algo mal, así que puse un punto de interrupción en él, pero el punto de interrupción no parece estar habilitado cuando empiezo a ejecutar la aplicación, y nunca es golpeado, lo que entiendo significa la DLL que contiene esa línea no está cargado. Lo más probable es que provoque una excepción al crear una instancia de un objeto de un tipo en el DLL: no se pudo encontrar el cuerpo del constructor del objeto.

He hecho esto con éxito en un proyecto diferente en el pasado, así que saqué un control de usuario WinForms diferente de esa aplicación, y lo instalé en el XAML, y todo funciona bien.

Esto es algo en esta DLL. Tengo una referencia a la DLL en mi aplicación WPF C#, y cuando cargo la DLL en el Examinador de objetos, todas las clases y espacios de nombres necesarios aparecen bien. La aplicación compila bien, el problema simplemente aparece al analizar el XAML. ¿Alguien ha visto algo como esto? ¿Alguna idea sobre qué podría estar causando esto? Ideas para depurarlo? ¡Gracias!

<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> 

Respuesta

10

He tenido problemas como ese (pero no con exactamente el mismo mensaje de error). Parece que WPF no puede crear una instancia de su Control de usuario de Winforms.

El desafío es descubrir por qué. Aquí están mis sugerencias que usted podría intentar:

  1. Comprobar si se ha habilitado la depuración no administrada (en Propiedades del proyecto -> Depuración)
  2. Estudia si hay dependencias de C++/CLI DLL en el que el control de Windows Forms es implementado y si esas dependencias no se pueden resolver.
    Para averiguar las dependencias en las DLL nativas, debe usar la herramienta Dependency Walker (depends.exe). .NET Reflector solo examinará las dependencias administradas.
  3. Comenta el código del Control de usuario de Winforms paso a paso y vuelve a intentarlo.
  4. Uso Gflags.exe para encender cargador Snaps (cf. Debugging LoadLibrary Failures)
+0

pregunta, # 1 debe estar habilitado o no ??? Tengo el mismo error y no está habilitado, ¿debería habilitarlo? –

+1

@macrian: Ha pasado un tiempo desde que escribí mi respuesta, pero creo que debería habilitar la depuración no administrada. De esta forma, verá más salidas en el depurador que podrían ayudarlo a rastrear el problema. – EFrank

+0

Lo sé, en realidad han pasado cuatro años: P gracias por su ayuda: D –

0

También tuve este problema y todo lo que tenía que hacer era entrar en las propiedades del proyecto> Seguridad y haga clic en el Esta es una solicitud de plena confianza. ¡Ejecuté mi proyecto otra vez y funcionó!

0

¿Estás seguro de que tienes el dll en la carpeta system32 o en la misma carpeta con el exe. Obtuve exactamente el mismo mensaje de error cuando ejecuté un proyecto WPF creado con CLI dll mientras el dll estaba ubicado en la carpeta diferente.

micrófono

1

que he visto este problema cuando se trata de impulsar el uso :: hilos. Para admitir el almacenamiento local de subprocesos, boost :: threads realiza algunas llamadas a la API Win32 que no son compatibles con las aplicaciones CLI. El problema se activa si intenta #incluir algo de los hilos en el código CLI.

La solución es evitar el uso de boost :: thread por completo o restringir su uso a archivos .cpp en código nativo.

1

Tenía síntomas similares y mi problema era que el proyecto C# estaba configurado para usar cualquier CPU mientras que el proyecto C++ estaba configurado para usar x86. Para configurar ambos para usar x86 se resolvió el problema

0

También tuve este mensaje de excepción, pero mis soluciones estaban cambiando el orden de los elementos XAML. Estaba usando un XmlDataProvider y mostrando el contenido en un cuadro de lista. Acabo de poner el XmlDataProvider antes del ListBox.

Cuestiones relacionadas