在我的 x64 笔记本电脑上将平台目标设置为 x86 会阻止某些 WPF 类型正确加载
我有一台运行 Windows 7 64 位的 x64 计算机。自本周初以来,我的情况似乎很奇怪。
如果我构建并运行一个平台目标设置为 x86 的 WPF 应用程序,则在尝试创建网格时出现 MissingMethodException:
var g = new Grid();
但是,创建 StackPanel 工作正常:
var s = new StackPanel();
如果我将平台目标切换到 x64 或 AnyCpu,则两个代码都工作正常。我正在考虑框架中的损坏的程序集,但它看起来确实很奇怪......有什么想法吗?
更新:
我一直在与 Microsoft 内部 WPF 团队的人员保持联系。然而,他们没有时间查看我的机器来了解问题所在。与此同时,我必须重新安装我的机器才能继续正常工作。谢谢大家的帮助。我认为这个问题与 WOW64 功能有关,但很难更准确。如果我找到更多信息,我会更新这个问题。
I have a x64 machine running Windows 7 64 bits. It seems I have a very weird situation since the beginning of the week.
If I build and run a WPF application with platform target set as x86, I got a MissingMethodException when trying to create a Grid:
var g = new Grid();
However, creating a StackPanel works fine:
var s = new StackPanel();
If I switch the platform target to x64 or AnyCpu, both code works fine. I was thinking about a corrupted assembly in the framework but it looks definitively strange... Any idea ?
Update:
I've been in contact with people within the WPF team inside Microsoft. However, they didn't had time to look at my machine to understand what was wrong. In the meantime, I had to reinstall my machine in order to keep working properly. Thank you all for your help. I think the problem was related to the WOW64 functionality, but it's hard to be more precise. I'll update this question if I found more info.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我也有这个配置,并且在构建使用网格的 x86 应用程序时没有遇到任何问题。
我会卸载您正在使用的 .NET Framework 版本(看起来像 .NET 4.0)并重新安装它。为了彻底起见,您还可以卸载 Visual Studio 2010 并重新安装它(尽管这可能有点过头了) )。
该问题必须仅存在于您正在使用的机器上……否则就会有暴民和干草叉之类的……前往华盛顿州雷德蒙德。 :-) 您可以尝试在另一台机器上创建一个示例项目......只是为了您的理智。 :-)
更新
我只是想添加 System.Windows.Controls.Grid 位于PresentationFramework 程序集中。查看此文件在您计算机上的存储位置可能会很有趣......看看您是否注意到任何事情。解决方案仍然可能是重新安装......但是嘿,更多信息总是更好。
对于 .NET 4.0,PresentationFramework 程序集位于:
C:\Windows\Microsoft.NET\ assembly\GAC_MSIL\PresentationFramework\v4.0_4.0.0.0__31bf3856ad364e35
对于 .NET 3.0/3.5,PresentationFramework 程序集位于:
C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0
I have this configuration as well and have experienced no issues with building an x86 application that uses a Grid.
I would uninstall the version of .NET Framework you are using (looks like .NET 4.0) and reinstall it. To be thorough, you might also uninstall Visual Studio 2010 and reinstall it (although that is probably overkill).
The problem has to exist on only the machine you are working on ... otherwise there would be mobs and pitchforks and such ... headed towards Redmond, WA. :-) You might try creating a sample project on another machine ... just for your sanity. :-)
Update
I just wanted to add that System.Windows.Controls.Grid lives in the PresentationFramework assembly. It might be interesting to take a look at where this file is stored on your machine ... to see if you notice anything. The solution is still probably reinstalling ... but hey, more information is always better.
For .NET 4.0, the PresentationFramework assembly lives at:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\PresentationFramework\v4.0_4.0.0.0__31bf3856ad364e35
For .NET 3.0/3.5, the PresentationFramework assembly lives at:
C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0
将平台目标设置为 x86 将导致您的应用程序在非托管程序集上调用 x86 版本并在 WOW64 模式下运行。请参阅这篇有关平台目标的文章和WOW64 上的此 msdn 页面。如果您跟踪 Reflector 中的静态 Grid 构造函数,它看起来像是一些线程初始化代码调用外部非托管函数“RuntimeHelpers.PrepareConstrainedRegions()”,这可能会导致问题(StackPanel 不会调用此代码)。这背后有一些猜测,但您可以尝试运行 Windows Update 以确保您拥有与同事相同的更新,并确保您也拥有所有 VS/.NET 更新。
最终,除非您从代码中调用一些仅作为 x86 程序集可用的第三方非托管 dll,否则您应该将平台目标保留为 Any CPU,以便它将在 x86 和 x64 平台上本机运行。
最后,如果运行 Windows 更新后您仍然遇到问题,如果可能的话,也更新您同事的电脑,看看问题是否会出现。如果确实如此,WOW64 层中可能存在错误,最好向 Microsoft 提交错误报告。
Setting the platform target to x86 is going to cause your application to call x86 versions on unmanaged assemblies and run in WOW64 mode. See this article on platform target and this msdn page on WOW64. If you trace the static Grid constructor in Reflector, it looks like some thread initialization code calls an externed unmanaged function "RuntimeHelpers.PrepareConstrainedRegions()" which could be causing the problem (the StackPanel doesn't call this code). There's a bit of speculation behind this, but you might try running Windows Update to make sure you have the same updates as your coworker, and make sure you have all the VS/.NET updates out there as well.
Ultimately, unless you're calling some 3rd party unmanaged dll's from your code that are only available as x86 assemblies, you should probably leave the platform target as Any CPU so it'll run native on x86 and x64 platforms.
Lastly, if after running windows update you're still seeing the problem, if possible, update your coworker's PC as well and see if the problem crops up. If it does, there could be a bug in the WOW64 layer, and it'd be good to file a bug report with Microsoft.