AnyCPU, x86, x64, ARM

今天終於稍微了解了 AnyCPU的用意了。特地記錄下來，避免記憶體 reset 的老問題。

Visual Studio.NET 2003

在這個年代之前，並沒有64位元的 CPU(應該說不普及)。此時 Visual Studio 並不提供 CPU 相關的選項。回想一下，這是多麼美好的事。

Visual Studio 2005，2008

也才再過個兩年，64 位元的 CPU 開始在伺服器上普遍了起來。到了2007年前後，連桌上電腦也愈來愈普及。為了面對問題，微軟 Visual Studio 2005 開始有了 AnyCPU 的平台目標選項。

那到底使用 AnyCPU 的 assembly 會如何的被地行呢？此時的決策是非常簡單，而且看來也十分有效：

當 assembly 使用的是 AnyCPU 平台目標時，且

• 執行在 32 位元Windows作業系統時，會以 32 位元的方式執行，IL 會被編譯成 x86 的 native code。
• 執行在 64 位元Windows作業系統時，會以 64 位元的方式執行，IL 會被編譯成 x64 的 native code。

問題

由於目前的64位元電腦 (Windows) 都是32位元相容的，因此一個 assembly 在64位元的電腦只能以 64 位元的方式來執行，恐怕不妙。我常碰到的例子是 Oracle Client。

當我們的存取 Oracle 資料庫的程式以 AnyCPU 編譯後，執行在 64 位元的電腦，會以 64 位元的方式來執行。但如果安裝的 Oracle Client 是32位元的呢？32 位元的 Oracle Client 載入 64 位元的程式，就會拋出 System.BadImageFormatException 例外。

Visual Studio 2010

上面的問題持續了3~4年，到底 32 位元與 64位元應用程式好壞也漸漸地有了較明確的選擇。

除非明確地需要大量的記憶體，或者需要長整數，否則32位元就已經足夠。64位元的效能還會有一些些下降。

因此，在 Visual Studio 2010，建立新專案時，Target Platform(平台目標) 預設就是 x86。
但是，AnyCPU 的assembly 執行方式仍然沒有變。

Visual Studio 2012

到了 Visual Studio 2012又有變化。這個時間點，正巧 ARM CPU (也是32bits)也要進來，因此 32bit === x86 時代正式終結。

Visual Studio 2012 建立新專案後的預設選項為 AnyCPU32BitPreferred。
注意一下， Prefer 32-bit 被 disable 掉，是指不能修改，但在.NET Framework 4.5 就可以設定了！

當 assembly 使用的是 AnyCPU 平台目標時，且

• 執行在 32 位元Windows作業系統時，會以 32 位元的方式執行，IL 會被編譯成 x86 的 native code。
• 執行在 64 位元Windows作業系統時，會以 64 位元的方式執行，IL 會被編譯成 x64 的 native code。
• 執行在 ARM Windows作業系統時，會以 32 位元的方式執行，IL 會被編譯成 ARM 的 native code。

因此，Perfer 32-bit 可以說是特地為 ARM 設計的。

結論

AnyCPU 從一開始，到目前其定義仍然沒有變動過。也就是「碰到ppp的作業系統，就執行成ppp的程式」，其中 ppp 可以是 32bit, 64bit, ARM。

改變的是「建立專案時的預設選項」。

也因此，上述 Oracle Client 的問題還是很可能會發生。建議儘可能地明確地指定平台目標(Target Platform)，以減少不確定性。

There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference

問題

使用Visual Studio 2012 建置專案時，出現了如下的錯誤

Warning    6    There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "msshrtmi, Version=1.8.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=AMD64", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.   

原因

我在這個專案使用了 Windows Azure的雲端 assembly msshrtmi，並且指定了 x64的版本。但在建置的設定上，卻指定為 Any CPU。雖然編譯會過，但一定要部署到 x64 的作業系統才能正常運作。

在 .NET 4.5 後 ，編譯會多出這樣的警告。

解決

一直出現這樣的警告實在很惱人。把該專案的 Platform target 設成 x64 就解決了這個問題

Visual Studio 2012 Test Platform

在 VS 2010 中寫單元測試，是一件簡單的事，但是內建的 ms-test 的效能卻是不好。而其他的 test framework 如 xUnit, MbUnit, NUnit 等，又難與 Team Foundation Server 整合。於是，只能一直使用 ms-test。

在 VS 2012 中，Test Framework 不再是單元測試中第一個要選擇的對象了。因為它有了新的概念：Unit Test Platform。

Unit Test Platform

簡單來說，我們現在可以在 VS12 中作許多不同Test Framework 的單元測試平台了。

安裝 xUnit Test Runner

在 Extensions and Updates 中，找到 xUnit Test Runner 並安裝。

接下來，建立一個平常的 Class Library, 並用 NuGet 安裝 xNnit ，以及引用 ms test framework. 完成如下圖的  References

再來，就寫測試吧。

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Text;

   5: using System.Threading;

   6: using Microsoft.VisualStudio.TestTools.UnitTesting;

   7: using Xunit;

   8:  

   9: namespace ClassLibraryTest

  10: {

  11:     [TestClass]

  12:     public class Class1

  13:     {

  14:         [Fact]

  15:         public async void Test()

  16:         {

  17:             var sut = new AsyncClass();

  18:             await sut.DoAsyncWork();

  19:             Xunit.Assert.Equal("Hello", sut.Property);

  20:         }

  21:  

  22:         [TestMethod]

  23:         public void Test2()

  24:         {

  25:             Microsoft.VisualStudio.TestTools.UnitTesting.Assert.IsTrue(true);

  26:         }

  27:     }

  28: }

執行測試

在左方的 Test Explorer，就可以看兩種不同的 Test Framework 的測試都可以被找到，且測試完畢。

結論

VS 2012 中的測試，看來又大幅提升了微軟在測試界的地位了。