好的,这真的很恼人。我之前已经注意到WPF生成的加载XAML资源的代码似乎没有使用强名称,因此可能会在需要支持WPF程序集并行版本的场景下出现问题。
这事情确实是这样,现在它给我带来了问题 - 我有一个插件系统,应该支持安装仅在其版本号(其程序集版本)不同的插件的并行安装。当然,.NET可以支持这一点,因为即使具有相同的DLL文件名,只要它们被强命名并且具有不同的公钥/私钥或不同的程序集版本号,则会确定程序集具有不同的标识。
现在,如果我们查看Visual Studio自动生成的Windows和UserControls的代码,我们会在自动生成的文件中看到以下内容:
/// <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隔离。