爲什麼我們可以在平臺獨立的情況下在.NET項目設置中更改平臺？

我正在使用visual studio 2010，.NET 4.0和WPF。我們正在嘗試將平臺項目構建爲「AnyCPU」，這將使計劃平臺保持中立。在這樣做的過程中，我開始迷惑自己。爲什麼我們可以在平臺獨立的情況下在.NET項目設置中更改平臺？

我認爲所有的.NET程序都是針對.NET框架而不是操作系統。如果是這種情況，我不必擔心我是在「x64」還是「x86」系統上工作。所有的程序目標都是.NET框架，它是一個適當的「運行時間」，它將自行處理。 CLR可以根據它所在的平臺分配內存，但.NET項目不應該擔心這一點。

我在這裏錯過了什麼？在.NET項目中構建設置時，「平臺」的要點是什麼？

來源

2012-01-31 Jimmy

將自己侷限於一種體系結構的一個常見原因是您使用僅支持一個平臺的本機庫。

例如，在我的一個項目中，我包含了libvorbis，我懶得編譯它的64位版本。所以我只將我的項目設置爲32位。一些其他本地庫可能根本不支持64位，特別是如果它們是封閉源遺留組件。

來源

2012-01-31 12:34:49 CodesInChaos

即使，它必須分別爲312或64位compield和鏈接英寸我很多項目謊言，一切都是任何cpu除了2版本的啓動exe - 一個在32位，一個在64位。 – TomTom 2012-01-31 12:36:13

在運行時可以在不同的庫之間進行選擇。例如在庫加載之前更改dll搜索路徑。 – CodesInChaos 2012-01-31 13:20:30

正如CodeInChaos所說，這是一個圖書館的問題。在x64下，您不能使用x86庫。在x86下，您可以運行x64庫。
Any cpu表示它將使用您當前的平臺設置（運行cpu）。

如果您想了解更詳細的，這裏是一個良好的閱讀：http://visualstudiohacks.com/articles/...

來源

2012-01-31 12:43:02

正如其他人所提到的，當你使用爲特定平臺上構建其他庫，您可能需要指定平臺。 COM就是一個很好的例子。

可以說你有一個32位的COM組件（大部分是），客戶端操作系統是32位。如果你爲「AnyCPU」編譯，它可以正常工作，因爲它將在本地x86代碼中運行，因爲你在32位系統上運行。

現在讓我們說你有相同的COM組件，客戶端OS是64位。在Windows上，當COM組件被註冊時，它將被註冊到註冊表的32位部分（我認爲是WOW6432Node）。因此，如果你的應用程序編譯爲「AnyCPU」，它將是一個本機64位應用程序，並且無法調用COM組件（導致類未註冊），因爲它將查找64位註冊表。如果你爲x64編譯，你將得到相同的錯誤（因爲它會在JIT之後產生相同的本地代碼）。但是如果你爲x86編譯，它將正常工作。

來源

2012-01-31 13:14:50

很好的解釋，謝謝。 – Jimmy 2012-01-31 14:31:30

爲什麼我們可以在平臺獨立的情況下在.NET項目設置中更改平臺？

回答

相關問題