爲什麼.NET開發人員提供.NET程序集的32位/ 64位版本？

Question

埃維現在，然後我看到一個.NET程序集的x86和x64版本。考慮以下web part for SharePoint。爲什麼開發人員不提供單個版本，並讓JIT編譯器將其餘部分整理出來？當我看到這些類型的產品時，開發人員決定使用類似ngen這樣的工具創建本機映像，以避免JIT？

有人請在這裏幫我，我覺得我失去了一些注意事項。

更新

從我下面什麼了，無論是x86和x64版本是提供，因爲一個或多個以下原因：

1. 開發人員希望避免JIT編譯並創建了一個原生他的代碼圖像，使用像ngen.exe這樣的工具針對特定的架構。

2. 該程序集包含平臺特定的COM調用，因此它沒有意義將其構建爲AnyCPU。在這些情況下，構建目標不同的平臺可能包含不同的代碼。

3. 該程序集可能包含使用pinvoke的Win32調用，該調用不會被JIT重新映射，因此構建應該以它綁定的平臺爲目標。

Answer 1

如果他們使用特定的非.Net API，那麼可能有兩個代碼庫，一個完美的例子是COM控件。

ngen也是你提到的另一個很好的理由。

Answer 2

當你編譯.net應用程序時，你必須在Build Settings中選擇一個Platform Target。選擇是AnyCPU，x86和x64。

一個常見的錯誤是在包含爲x86編譯的本機DLL的項目中指定AnyCPU。這在64位機器上運行時會導致錯誤，這是在64位機器上測試的一個很好的理由。

因此，爲了支持被其他依賴項強制直接構建x86或x64的人，程序集提供了這兩種方法。

Answer 3

COM處理跨越32/64位邊界的封送和解組。但是，它沒有提供任何支持將可選類型的二進制文件加載到公寓的錯誤指針寬度中。

許多程序集都依賴本地代碼（例如，大多數SQL驅動程序都是用C或C++編寫的）。對於使用p/invoke的任何事情來說，這是非常明顯的。因此，編譯和分發不同的指針寬度意味着64位版本的軟件包很可能包含64位本機DLL，並且32位版本可能包含32位本機DLL。即使程序集的32位和64位版本是用相同的代碼編譯的，情況也是如此。

如果您要求，csc將生成原生（pre-JITted）圖像。