如何恢復Visual Studio 2010配置管理器的默認設置

Question

在使用Visual Studio配置管理器進行了一些「遊戲」之後，我發現在Visual Studio中創建的每個新的C＃/ VB.NET項目都只有'x86'解決方案平臺它應該是'任何CPU'，如果需要，我應該可以選擇x86或x64。如何爲所有新項目重置這些設置？

Answer 1

你確定這是問題嗎？也許你應該將「顯示高級構建配置」設置爲詳細here。

Answer 2

Microsoft將EXE的默認值更改爲x86。由裏克·拜爾斯看看這篇文章：

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項目的默認：

• 以兩種非常不同的模式運行會增加產品的複雜性和測試成本 *通常人們不會意識到架構中立程序集本機互操作帶來的影響。它 意味着您需要確保您所依賴的本機DLL的等效32位和64位版本 可用，並且（最顯着） 會自動選擇合適的DLL。當調用OS API時，由於在WOW中運行的c：\ windows \ system32 到c：\ windows \ syswow64的操作系統重新映射以及操作系統團隊的廣泛測試 ，調用OS API時，這非常容易 。但是許多人將原生DLLs與 一起發佈，他們的託管應用程序一開始就出現這種錯誤，並且很驚訝於他們的 應用程序在64位系統上爆炸，32位DLL的 格式不正常。此外，雖然它比原生代碼的 更爲罕見，但指針大小的錯誤仍然可以在.NET中顯示（例如，假設IntPtr與Int32相同，或者在與本機代碼交互時不正確地編組 聲明時，則爲 ）。 *此外，除了需要知道遵循的規則 之外，還有隻是 您現在真的有兩倍的代碼來測試的問題。例如，在CLR的一個體繫結構上可以容易地（並且肯定已經有許多）CLR錯誤重現 ，並且這適用於整個堆棧（從OS，框架，第三方庫到你的代碼）。當然，在理想的世界中，每個人都測試了32位和64位的 ，並且你不會看到任何差異，但是在實踐中對於任何大型應用程序來說都沒有什麼差別，而且在實踐中 微軟至少）最終將我們的整個測試系統複製爲32位和64位的 ，併爲測試支付大量持續成本，並支持所有平臺的 。 * [編輯：波多黎各 - CLR和VS性能 建築師成名的 - 剛剛發佈了爲什麼Visual Studio中 不會是一個純粹的64位應用程序anytmie一個偉大的博客條目很快]
• 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可以解決問題，但仍然沒有讓人們浪費像這樣的錯誤。