Да, это действительно раздражает, я заметил ранее, что код, сгенерированный WPF для загрузки ресурсов XAML, похоже, не использует строгие имена и, следовательно, может быть проблематичным для сценариев, когда вам необходимо поддерживать параллельные версии сборок WPF.

Это оказалось так, и теперь это вызывает у меня проблемы - у меня есть система плагинов, которая должна поддерживать установку плагинов бок о бок, которые отличаются только номерами версий (версиями сборки). Это, конечно, может поддерживаться .NET, поскольку сборки имеют разные идентификаторы, даже если они имеют одно и то же имя файла DLL, при условии, что они имеют строгое имя и либо имеют открытый / закрытый ключ, либо имеют другой номер версии сборки.

Теперь, если мы посмотрим на код, сгенерированный для windows и usercontrols Visual Studio, мы увидим в автоматически сгенерированном файле следующее:

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

Обратите внимание на строку, где создается локатор ресурса - он использует относительный URI, который не указывает строгое имя или версию сборки, которая содержит ресурс xaml.

Я подумал, что, возможно, LoadComponent проверит идентичность вызывающей сборки и использует ее открытый ключ и сведения о версии, или, возможно, проверит идентичность сборки, которая содержит тип для параметра 'this'.

Похоже, что это не так - если у вас есть две сборки с разными номерами версий (но с одинаковым именем файла), вы можете получить IOException с сообщением «Не удается найти ресурс X» (для приведенного выше примера «Невозможно найти ресурс» views / servicepanelui .xaml.

Хуже того, я почти уверен, что это также будет означать, что сборки с одинаковым именем файла, но с разным открытым / закрытым ключом, то есть от разных издателей, также приведут к этой ошибке.

Итак, кто-нибудь знает, как обойти это? Как сделать WPF совместимым со строгим именем.

Обратите внимание, что, насколько мне известно, это ошибка WPF. Вам не нужно использовать изоляцию Appdomain, чтобы избежать этого.