O.k., das ist wirklich irritierend. Ich hatte zuvor bemerkt, dass der von WPF zum Laden von XAML-Ressourcen generierte Code anscheinend keine starken Namen verwendet und daher für Szenarien problematisch sein kann, in denen Sie Versionen von WPF-Assemblys nebeneinander unterstützen müssen.

Es hat sich herausgestellt, dass dies der Fall ist, und es verursacht mir jetzt Probleme: Ich habe ein Plug-In-System, das die Installation von Plug-Ins nebeneinander unterstützen soll, die sich nur in ihren Versionsnummern (ihren Assembly-Versionen) unterscheiden. Dies kann natürlich von .NET unterstützt werden, da Assemblys unterschiedliche Identitäten aufweisen, auch wenn sie denselben DLL-Dateinamen haben, sofern sie stark benannt sind und entweder einen anderen öffentlichen / privaten Schlüssel oder eine andere Assembly-Versionsnummer haben.

Wenn wir uns nun den von Visual Studio für Windows und Benutzersteuerelemente generierten Code ansehen, sehen wir in der automatisch generierten Datei Folgendes:

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

Beachten Sie die Zeile, in der der Ressourcen-Locater erstellt wird - er verwendet einen relativen URI, der weder den starken Namen noch die Version der Assembly angibt, die die XAML-Ressource enthält.

Ich dachte, LoadComponent prüft möglicherweise die Identität der aufrufenden Assembly und verwendet deren öffentlichen Schlüssel und Versionsdetails oder prüft möglicherweise die Identität der Assembly, die den Typ für den Parameter 'this' enthält.

Dies ist anscheinend nicht der Fall. Wenn Sie zwei Assemblys mit unterschiedlichen Versionsnummern (aber demselben Dateinamen) haben, können Sie eine IOException mit der Meldung "Ressource X kann nicht gefunden werden" abrufen (Beispiel oben: "Ressourcenansichten / Servicepanel können nicht gefunden werden") .xaml '.

Schlimmer noch, ich bin mir ziemlich sicher, dass dies auch bedeuten wird, dass Assemblys mit demselben Dateinamen, aber unterschiedlichen öffentlichen / privaten Schlüsseln, d. H. Von unterschiedlichen Herausgebern, ebenfalls zu diesem Fehler führen.

Weiß jemand, wie man das umgeht? So machen Sie WPF-Namen konform.

Beachten Sie, dass dies für mich ein WPF-Fehler ist. Sie sollten nicht die Appdomain-Isolierung verwenden müssen, um dies zu vermeiden.