AssemblyResolve 总是被提出，请求 MyAssembly.resources
我有一个 WPF 应用程序，并且订阅了事件 AppDomain.AssemblyResolve< /a> （每当运行时找不到程序集时就会引发此事件），我注意到它会多次调用以尝试解析 MyAssembly.resources，其中 MyAssembly 是当前正在执行的程序集。它还对我从 MyAssembly 引用的库程序集提出了同样的要求（它要求 Library.resources）。
这是正常的吗？我该如何修复它？我的应用程序确实有问题。它无法加载位于库中的某些 xaml 用户控件。这有关系吗？
I have a WPF application, and I subscribe to the event AppDomain.AssemblyResolve (this event get raised whenever the runtime does not find an assembly), and I notice it gets call several times trying to resolve MyAssembly.resources, where MyAssembly is the current executing assembly. It also asked the same thing for a library assembly I referenced from MyAssembly (it asked for Library.resources).
Is this normal? How do I fix it? My application does have a problem. It cannot load some xaml user control located in the library. Is this related?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
将此行添加到您的 AssemblyInfo.cs 中，您的解析器将不再被要求提供资源。
尽管这是一种解决方法，但应该仔细考虑多语言应用程序。
更多信息：
Add this line to your AssemblyInfo.cs and your resolver will not get asked for resources any-more.
Though this is a work-around should be carefully considered multi-language applications.
More Info:
我们在使用
AssemblyResolve事件处理程序时遇到了同样的问题。奇怪的是，我们只在 Windows XP 机器上看到这个问题。我们的应用程序已本地化为多种语言，因此我们对于是否使用 NeutralResourcesLanguageAttribute 犹豫不决。我们的应用程序是针对 .NET v3.5 编译的，但仍然受到AssemblyResolve更改 针对 .NET v4.0 记录：我们解决这个问题的方法是检查
e.Name并查看它是否正在寻找*.Resources.dll。如果在 AppDomain 或已知文件夹中找不到该文件，我们将删除“.Resources”并查找 *.dll。如果该文件存在，我们将加载并返回该程序集。这为我们解决了问题。We ran into this same problem with an
AssemblyResolveevent handler. Oddly, we only saw the issue on Windows XP machines. Our application is localized to many languages, so we were hesitant to use theNeutralResourcesLanguageAttribute. Our application was compiled for .NET v3.5, but was still being affected by theAssemblyResolvechange documented for .NET v4.0:The way we resolved this was to check
e.Nameand see if it was looking for *.Resources.dll. If that file was not found in the AppDomain or known folder, we would remove ".Resources" and look for *.dll. If that file exists, we load and return that assembly. This resolved the problem for us.您可以使用fuslogvw.exe来查看.Net在哪里尝试寻找您的依赖项。
请参阅http://msdn.microsoft.com/en-us/library/e74a18c4。 aspx 了解更多信息。
You can use fuslogvw.exe in order to see where .Net is trying to look for your dependencies.
See http://msdn.microsoft.com/en-us/library/e74a18c4.aspx for more info.