使用Visual Studio Configuration Manager进行一些“游戏”后，我发现我在Visual Studio中创建的每个新的C＃/ VB.NET项目都只有'x86'解决方案平台。它应该是'Any CPU'，如果需要，我应该可以选择x86或x64。如何为所有新项目重置这些设置？
答案 0 :(得分：1)
Microsoft将EXE的默认值更改为x86。看看Rick Byers的这篇文章：
这是我在讨论中用来证明制作合理性的清单 x86是Visual Studio中EXE项目的默认值：
- 以两种截然不同的模式运行会增加产品复杂性和测试成本 *通常人们都没有意识到 对架构中立组件的本地互操作的影响。它 意味着您需要确保等效的32位和64位版本 您所依赖的本机DLL是可用的，并且（最重要的） 自动选择适当的一个。这很容易 由于操作系统重新映射c：\ windows \ system32而调用OS API时 在WOW和广泛测试中运行时到c：\ windows \ syswow64 操作系统团队。但许多人一起发布本机DLL 他们的托管应用程序一开始就搞错了，然后他们感到惊讶 应用程序在64位系统上爆炸，但有关它们的例外情况 32位DLL格式错误。而且，虽然比它更罕见 对于本机代码，指针大小的错误仍然可以在.NET中显示（例如。 假设IntPtr与Int32相同或不正确的编组 与本机代码交互时的声明）。 *另外，还有 根据您需要了解的规则，只有问题 你现在真的有两倍的代码来测试。例如，有可能 容易（并且肯定有很多）CLR错误只能重现 在CLR的一个体系结构上，这适用于所有方式 堆栈（从操作系统，框架，第三方库到您的代码）。的 在一个理想的世界里，每个人都做了很好的测试 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位 对于JIT团队而言，EnC本来是一项非常重要的成本 决定他们的时间花在更高优先级的功能上。 CLR之外还有其他很酷的功能 特定于x86 - 与VS 2010中的历史调试一样。复杂 这里的问题是我们并没有总是在错误方面做得很好 消息，所以有时人们“升级”到64位操作系统 然后反感看到他们的某些功能不再出现了 工作（没有意识到，如果他们只是重新定位他们的WOW 工作得很好）。例如，VS中的EnC错误不是很清楚 （“不允许对64位应用程序进行更改”），并导致 在实践中有些困惑。我相信我们做的是正确的 VS2010并修复该对话框，以明确切换您的 项目到x86可以解决问题，但仍然没有得到 回到人们浪费在这样的错误上的时间。
答案 1 :(得分：0)
你确定这是问题吗？也许您应该将“显示高级构建配置”设置为详细here。