我注意到，如果我为任何 CPU/x64 构建 WPF 应用程序，则与在 x86 上启动（在发布和调试模式下）相比，启动（大约 20 秒）或加载新控件所需的时间要长得多，VS 的内部或外部）。即使是最简单的 WPF 应用程序也会出现这种情况。该问题讨论于这个 MSDN 线程 http://social.msdn.microsoft.com/Forums/en/netfx64bit/thread/476e21c4-6b73-4f8e-bfab-a7aaae5b017f，但那里没有提供答案。这种情况仅发生在 .NET 4.0 中——在 3.5 SP1 中，x64 与 x86 一样快。有趣的是，微软似乎知道这个问题，因为 VS2010 中新的 WPF 项目默认是 x86。
这是一个真正的错误还是我只是做错了？
EDIT:可能与此相关：C# .NET 4.0 中的数据绑定设置时间缓慢 https://stackoverflow.com/questions/2788215/slow-databinding-setup-time-in-c-net-4-0。我大量使用数据绑定。
实际上，WPF 应用程序的默认项目类型是 x86 有两个主要原因。
- Intellitrace 调试仅适用于 x86，如果默认项目模板不能使用其明星功能之一，那看起来会很糟糕。
- 许多开发人员仍然不知道他们的 AnyCPU exe 可以在 64 位计算机上以 x64 运行，并且惊讶地发现他们所依赖的 32 位 DLL 在 64 位版本中并不存在，例如 OLEDB 驱动程序、某些本机 DLL 等。
至于您遇到的启动时间问题，它几乎看起来像是 NGEN 的问题。由于 x64 和 x86 进程有不同的 NGEN 缓存，因此可能需要重建或更新 64 位 NGEN 缓存。尝试从提升的命令提示符运行以下命令：
CD C:\Windows\Microsoft.NET\Framework64\v4.0.30319
NGEN update
这是为已标记为 NGEN 的程序集重新构建本机映像的命令。如果程序集不在 GAC 中，那么它也可能不会对您的应用程序的 NGEN 产生任何好处，因此我不会费心尝试这样做。但框架程序集、工具包程序集等都应该是 NGEN 的。
（顺便说一句，当我运行上述命令时，我确实遇到了一些关于无法加载程序集的错误。主要是 SQL 和 Visual Studio 程序集。）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
