c# - proyectos - wpf vs windows forms

El recurso de lanzamiento de control WPF ''identificado por la excepción URI faltante''

Question

Al cargar el complemento e intentar crear el control ''XYZ'', la aplicación lanza la siguiente excepción:

"El componente ''XYZ'' no tiene un recurso identificado por el URI ''/ThePluginAssembly;component/XYZ.xaml''" en el método InitializeComponent () en el constructor UserControls.

Los puntos clave son:

1. El control de usuario se encuentra en el conjunto de plugin.

2. Estoy intentando crear el control de usuario desde dentro del ensamblaje del complemento

3. Los complementos se encuentran en el mismo directorio que la aplicación principal.

4. Los controles de usuario solo tienen problemas cuando se crean a través de XAML. Tengo un par de otros controles de usuario en el mismo ensamblaje, pero los instalo usando el código. Solo recibo el mensaje de error cuando intento crear un UserControl en XAML.

Al hacer un poco de google, me di cuenta de que esto sucede cuando se cargan dos instancias de mi complemento en la aplicación. Cuando quité mi complemento de una de las carpetas (permito que este complemento se cargue desde dos ubicaciones) esta excepción dejó de repetirse.

Mis preguntas:

1) ¿Cuál es la razón detrás de que WPF intente resolver un URI para cargar mi control?

2) ¿No hay una manera en la que pueda tener dos instancias de mi complemento cargado en la aplicación y deshacerme de esta excepción? o alguna forma de crear un URI único para cada instancia (si esta excepción es causada por un URI en conflicto).

Cualquier comentario o referencia sería de ayuda.

Gracias por tu interés.

Edición: El mismo problema que publicó Phil: ¿Cómo obligar a WPF a usar URI de recursos que usan un nombre seguro de ensamblaje? Argh!

Answer 1

Copie todos los archivos de la carpeta bin en una carpeta separada de todos los proyectos que se encuentran en su solución y elimine la carpeta de depuración y liberación de la carpeta bin de cada proyecto. Esto ha resuelto el problema del diseñador para mí.

Recuerde que la próxima vez que compile todos los archivos volverá a aparecer. Por lo tanto, debe tener algún script en la compilación posterior para poder copiar en otra carpeta y eliminar los archivos en la carpeta bin.

Answer 2

Hasta ahora, la mejor solución a la que he llegado, es modificar el nombre de mi plugin dll en las propiedades del proyecto y hacerlo específico para la versión.

Entonces, si inicialmente era "prod.myplugin" ahora lo he hecho "prod.myplugin_300d3". Después de modificar las propiedades del proyecto cuando reconstruyo mi proyecto, el compilador regenera los archivos .g.cs, y ahora tiene una versión en el URI (aparece como /pr.myplugin_300d3;component/XYZ.xaml) y, por lo tanto, hace que mi URI sea único. A través de diferentes versiones.

Todavía estoy buscando una solución mejor y automatizada donde pueda modificar MSBuild: Compile la configuración.

Answer 3

La única forma de hacerlo sería incluir la información de la versión en su URI, de modo que el cargador XAML pueda distinguir el tipo correcto. Este artículo de MSDN explica el formato del paquete URI, y la parte de la versión tiene esta descripción:

; Versión [opcional]: la versión del ensamblaje al que se hace referencia que contiene el archivo de recursos. Esto se utiliza cuando se cargan dos o más conjuntos referenciados con el mismo nombre corto.

Así que querrás usar uno de los siguientes:

/ThePluginAssembly;v1.0.0.0;component/XYZ.xaml
/ThePluginAssembly;v1.1.0.0;component/XYZ.xaml

Answer 4

Las siguientes instrucciones son relevantes tanto para el conjunto del complemento como para cualquier conjunto que no sea del sistema al que hace referencia el complemento (la duplicación podría estar en cualquier nivel de referencias).

Dado que el ensamblado del complemento se encuentra en el directorio ejecutable de la aplicación,
Si agregó su ensamblaje al GAC, quítelo de allí.

Verifique todas las referencias al conjunto desde su solución y configure "Versión específica" en falso.

Si el ensamblaje del complemento es de otra solución y utiliza versiones diferentes del ensamblado para debug / release o para x86 / x64, edite los archivos .csproj que hacen referencia al ensamblaje y establezca una ruta de referencia como en este ejemplo .

Considere la posibilidad de cancelar la referencia a los ensamblajes de complementos y usar la reflexión para cargarlos en su lugar, esto eliminará las dependencias de la solución de los complementos.
Para hacer esto, deberá mover cualquier código que busque elementos específicos en los complementos a los propios ensamblajes de complementos y, desde la solución original, solo los tipos de acceso expuestos mediante complementos que admitan interfaces definidas fuera del complemento (por ensamblajes en la solución original o en un ensamblaje referenciado tanto por la solución original como por el plugin).
- Al acceder al ensamblaje a través de la reflexión, asegúrese de cargar el ensamblaje desde el directorio ejecutable de la aplicación.

Asegúrese de que los URI del paquete a los recursos son de la forma: "paquete: // aplicación: ,,, / ReferencedAssembly; component / Subfolder / ResourceFile.xaml"

Answer 5

intente utilizar Assembly.LoadFrom() lugar de Assembly.Load() o Assembly.LoadFile() .

Tuve el mismo problema: solía cargar ensamblados con Assembly.LoadFile() . Después de buscar por días, descubrí que Assembly.LoadFile() y Assembly.Load() están en desuso. Ambos métodos crean problemas en el tiempo de ejecución. Así que usé Assembly.LoadFrom() y funcionó.