¿Cómo forzar a WPF a usar los URI de recursos que usan el nombre fuerte de ensamblado? Argh!

Ok, esto es realmente irritante, ya había notado anteriormente que el código generado por WPF para cargar recursos XAML no parecía usar nombres fuertes y, por lo tanto, puede ser problemático para escenarios en los que necesite soportar versiones de ensambles WPF lado a lado.

Este ha sido el caso, y ahora me está causando problemas. Tengo un sistema de complemento que se supone que es compatible con la instalación paralela de complementos que solo difieren en sus números de versión (sus versiones de ensamblaje). Esto por supuesto puede ser soportado por .NET ya que se determina que los ensamblados tienen diferentes identidades incluso si tienen el mismo nombre de archivo DLL, siempre que tengan un nombre fuerte y que tengan una clave pública / privada diferente O tengan un número de versión de ensamblaje diferente.

Ahora, si miramos el código generado para Windows y controles de usuario por Visual Studio, vemos en el archivo autogenerado lo siguiente:

///  /// InitializeComponent ///  [System.Diagnostics.DebuggerNonUserCodeAttribute()] public void InitializeComponent() { if (_contentLoaded) { return; } _contentLoaded = true; System.Uri resourceLocater = new System.Uri("/Sensormatic.AMK1000.Panel;component/views/servicepanelui.xaml", System.UriKind.Relative); #line 1 "..\..\..\Views\ServicePanelUI.xaml" System.Windows.Application.LoadComponent(this, resourceLocater); #line default #line hidden } 

Observe la línea donde se crea el localizador de recursos: está utilizando un URI relativo que no especifica el nombre fuerte o la versión del ensamblado que contiene el recurso xaml.

Pensé que quizás LoadComponent verificaría la identidad del ensamblado que llama y usaría su clave pública y detalles de la versión o tal vez verificaría la identidad del ensamblado que contiene el tipo para el parámetro ‘this’.

Parece que este no es el caso: si tiene dos ensamblajes con diferentes números de versión (pero el mismo nombre de archivo), puede obtener una IOException con el mensaje “No se puede localizar el recurso X” (para el ejemplo anterior “No se pueden encontrar recursos” views / servicepanelui .xaml ‘.

Peor aún, estoy bastante seguro de que esto también significará que los ensamblados con el mismo nombre de archivo pero diferente clave pública / privada, es decir, de diferentes editores, también generarán este error.

Entonces, ¿alguien sabe cómo evitar esto? Cómo hacer que WPF sea compatible con el nombre.

Tenga en cuenta que, en lo que a mí respecta, este es un error de WPF. No debería tener que usar el aislamiento Appdomain solo para evitar esto.