O.k, esto es realmente irritante, había notado previamente 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 es necesario admitir versiones en paralelo de los conjuntos de WPF.

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

Ahora, si observamos el código generado para windows y usercontrols por visual studio, vemos en el archivo generado automáticamente lo siguiente:

/// <summary>
/// InitializeComponent
/// </summary>
[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: utiliza un URI relativo que no especifica el nombre seguro ni la versión del ensamblaje que contiene el recurso xaml.

Pensé que LoadComponent verificaría la identidad del ensamblaje llamante y usaría su clave pública y los detalles de la versión, o tal vez verificaría la identidad del ensamblaje 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 excepción IO con el mensaje "No se puede localizar el recurso X" (para el ejemplo anterior "No se puede encontrar el recurso 'views / servicepanelui .xaml '.

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

Entonces, ¿alguien sabe cómo solucionar esto? Cómo hacer que el nombre fuerte de WPF sea compatible.

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