如何恢复 Visual Studio 2010 配置管理器的默认设置

Question

在使用 Visual Studio 配置管理器进行一些“游戏”后，我发现我在 Visual Studio 中创建的每个新 C#/VB.NET 项目都只有“x86”解决方案平台。它应该是“任何 CPU”，如果需要，我应该能够选择 x86 或 x64。如何为所有新项目重置这些设置？

Answer 1

Microsoft 将 EXE 的默认设置更改为 x86。查看 Rick Byers 的这篇文章：

http://blogs.msdn.com/b/rmbyers/archive/2009/06/09/anycpu-exes-are-usually-more-trouble-then-they-re-worth.aspx

这是我在讨论中一直使用的清单，以证明制作的合理性 x86 默认为 Visual Studio 中的 EXE 项目：

• 以两种截然不同的模式运行会增加产品复杂性和测试成本 * 人们通常没有意识到 对架构中立程序集的本机互操作的影响。它 意味着您需要确保等效的 32 位和 64 位版本的 您依赖的本机 DLL 可用，并且（最重要的是） 会自动选择合适的。这很容易 由于 c:\windows\system32 的操作系统重新映射而调用操作系统 API 时 到 c:\windows\syswow64 在 WOW 中运行并进行大量测试时 操作系统团队确实如此。但是很多人同时提供原生 DLL 他们的托管应用程序一开始就犯了这个错误，然后感到惊讶 应用程序在 64 位系统上崩溃，但它们的异常 32 位 DLL 格式错误。此外，虽然它比 对于本机代码，指针大小的错误仍然可以在 .NET 中出现（例如。 假设 IntPtr 与 Int32 相同，或编组不正确 与本机代码互操作时的声明）。 * 此外，此外 对于你需要知道遵守的规则，有一个问题是 你现在真的有两倍多的代码要测试。例如，可以 很容易成为（当然也有很多）只重现的 CLR 错误 在 CLR 的一种架构上，这一直适用于 堆栈（从操作系统、框架、第 3 方库到您的代码）。的 当然，在一个理想的世界里，每个人都做得很好，测试两者 32 位和 64 位，您不会看到任何差异，但实际上 对于任何并非如此的大型应用程序，并且（在 至少微软）我们最终复制了我们的整个测试系统 32 位和 64 位，并为测试和 支持所有平台。 * [编辑：Rico - CLR 和 VS 性能 建筑师声望 - 刚刚发布了一篇关于为什么使用 Visual Studio 的精彩博客文章 不会很快成为纯 64 位应用程序]
• 无论如何，32 位往往更快 * 当应用程序可以在 32 位或 64 位模式下正常运行时，32 位模式往往是 快一点。更大的指针意味着更多的内存和缓存 消耗，可用的 CPU 缓存字节数为 32 位和 64 位进程相同。当然是WOW层 确实增加了一些开销，但我看到的性能数字表明 在 WOW 中运行的大多数真实场景中比 作为本机 64 位进程运行
• 某些功能在 64 位中不可用 * 虽然我们都希望在 32 位和 64 位之间实现完美的奇偶校验，但现实情况是 我们还没有做到。 CLR v2 仅支持混合模式调试 在 x86 上，虽然我们最终在 CLR V4 中添加了 x64 支持， 编辑并继续仍然不支持 x64。在 CLR 团队中，我们 每当我们添加新的时，将 x64 视为一等公民 功能，但现实是我们有一个复杂的 代码库（例如，完全独立的 32 位和 64 位 JIT 编译器） 并且我们有时不得不做出取舍（例如，添加 64 位 EnC 对 JIT 团队来说是一笔非常大的成本，而我们 决定他们的时间最好花在更高优先级的功能上）。 CLR 之外还有其他很酷的功能 特定于 x86 - 类似于 VS 2010 中的历史调试。 这里的问题是我们并不总是在错误方面做得很好 消息，因此有时人们“升级”到 64 位操作系统并且 然后厌恶地看到他们的一些特征似乎不再 工作（没有意识到如果他们只是重新定位WOW，他们会 工作正常）。比如VS中的EnC错误不是很清楚 （“不允许更改 64 位应用程序”），并导致 实践中的一些混乱。我相信我们在做正确的事 VS2010 并修复该对话框以明确切换您的 项目到 x86 可以解决问题，但仍然没有得到 回顾人们在此类错误上浪费的时间。

Answer 2

您确定这是问题所在吗？也许您应该将“显示高级构建配置”设置为详细的here。