[VS2010] Visual Studio 2010 與 Windows Azure 準備篇 (3) : 認識 Development Fabric 與 Development Storage
不論是用 Visual Studio Tools for Windows Azure，或是直接安裝 Windows Azure SDK，都可以在電腦中找到兩個奇怪的東西，一個是 Development Fabric，一個是 Development Storage，這兩個是用來做為模擬 Windows Azure 實際運作環境的服務程式，在本機上開發 Windows Azure 應用程式時，若要偵錯就不能沒有它，否則還要跑 Windows Azure 網站上傳後再測試，那可是很累人的，而且除錯器跨網路的話效能會差很大，有個本地端的模擬工具對開發人員來說方便很多，至少在測試時省下的時間會比沒有多太多了。
Development Fabric 的功用是模擬部署，執行以及在程式中實作的記錄與診斷 (Logging and Diagnostics) 的功能，Development Fabric 本身就是一個 Windows Azure Fabric (雲端中的 Windows Azure 執行代理程式) 的本機版本，上面搭載的是 Windows Azure Guest OS，也就是應用程式實際執行的作業系統環境，於 Windows Azure SDK 1.1 (二月份的版本) 中，可以藉由設定服務組態檔 (Service Configuration File) 來設定應用程式要使用哪一個 Windows Guest OS 版本，預設當然都是使用最新的版本，Development Fabric 允許開發人員設定使用不同的 Windows Guest OS，但是該功能只適用於以舊版 SDK 開發的應用程式，新的版本還是以最新的 Windows Guest OS 為宜。
Development Fabric 在 Visual Studio 啟動雲端應用程式時，它是在背景執行的一個服務，只會在工作列上顯示一個圖示：
如果要特別顯示它的使用者介面，則要由那個圖示的快顯功能表中選擇 [Show Development Fabric UI]：
選取之後，Development Fabric 的使用者介面才會出現：
這個使用者介面可以做的事有：
1. 監控應用程式的執行狀況。
2. 若應用程式會輸出 Log 記錄，則可以在這裡看到，這對 Worker Role 或 WCF Service 型的應用程式會很有幫助。
3. 測試服務停止與啟動時的反應 (OnStart() 與 OnEnd() 事件常式的處理反應)。
前面也已經說到，Development Fabric 是一個模擬的環境，就像是 ASP.NET Development Server 之於 IIS 一樣，它和正式的 Windows Azure 環境會有部份差異，有些差異則是開發人員必須要注意的：
1. 除錯器不能掛到正式的 Windows Azure 環境，任何除錯用的訊息都要用 log 來輸出。
2. Development Fabric 中運行的 Windows Azure 應用程式可以存取本機的系統資訊，如 GAC/Registry/Machine Configuration 與本機系統資源等等，但這些東西在正式的 Windows Azure 環境中沒有。
3. Development Fabric 可以直接將記錄資訊輸出到 UI 中，如同使用 Windows Azure Diagnostics 抓取的一樣，但在正式的 Windows Azure 環境中，只能用 Windows Azure Diagnostics API 將訊息存到 Table Storage。
4. 在正式的 Windows Azure 環境中，開發人員可以利用服務組態檔在不重新部署應用程式的情況下設定執行的 role instance 數量，但在 Development Fabric 中這個功能不支援，只能重新部署。
5. Development Fabric 無法完全模擬 Windows Azure Load Balancer (負載平衡器) 的所有行為。
另外一個模擬環境是 Development Storage，它則是模擬在雲端中的 Windows Azure Storage Services，包括 BLOB, Table 以及 Queue Service 都由它來模擬，因此它會需要一個儲存的地方。依照預設，Development Storage 會存取本機的 SQL Server Express (./SQLEXPRESS) 以建立一個它專屬的資料庫，因此若電腦中沒有安裝 SQL Server Express，在啟動 Development Storage Service 時會出現下列的訊息：
那麼如果本機上有 SQL Server 但不是 SQL Server Express 怎麼辦？不用擔心，Windows Azure SDK 有提供一個工具：DSInit.exe (Development Storage Initialization Tool，這個工具存放在 %PROGRAM_FILES%\Windows Azure SDK\v1.1\bin\devstore 目錄中，你也可以由 Windows Azure SDK 所建立的 “Windows Azure SDK Command Prompt” 來執行它)，它可以允許開發人員自行設定 Development Storage 要使用的 SQL Server 執行個體，因此如果要設定 SQL Server 的預設執行個體，可以下這樣的指令：
dsinit /sqlinstance:.
這樣 DSInit 就會連結到 SQL Server 預設的執行個體，而看到的訊息就是這樣：
此時就可以由 SQL Server Management Studio 來看由 Development Storage 所建立的資料庫，名稱是固定的 DevelopmentStorage20090919，表格配置則是：
它也安裝了一些輔助的預存程序以及函數：
有了 Development Storage 服務，開發人員也才能在本機使用 Microsoft.WindowsAzure.StorageClient 來開發應用 Windows Azure Storage 的應用程式。而 Development Storage 本身也有一個使用者介面，用來設定要執行哪些 Storage Service：
Development Storage 所開放的 Storage Service 終端點，都是以本機 URL 用不同的 Port 所切分，和 Windows Azure Storage 實際開放的 URL 是不一樣的，開發人員在利用本機發展完應用程式後要記得做轉換 URL 的動作，否則在雲端上會失效。另外，Development Storage 本身有提供一個存取的 Key:
Account name: devstoreaccount1 Account key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
以模擬實際在 Windows Azure Storage 存取服務時要提供 Account name 以及 Account key 一樣，這也是開發人員需要在部署到雲端前要做的更換工作。
Development Storage 與 Windows Azure Storage 的差異有：
1. Development Storage 和正式的 Windows Azure Storage 的服務 URL 不相同，正式的 Windows Azure Storage 的 URL 是：
<http|https>://<account-name>.<service-name>.core.windows.net/<resource-path> （service-name 是下列三種值之一：blob, table 與 queue）
2. Development Storage 沒有 Scale 能力，也無法支援大量的同時使用者。
3. Development Storage 使用固定的 Account name 與 Account key，如上所述。
4. 本機的 BLOB Service 大小最高 2GB。
5. 在 Development Storage 的 Table Service 中的日期範圍，與 SQL Server 2005 所支援的日期範圍相同。
6. 在 Development Storage 的 Table Service 可以支援 partition key 與 row key 的屬性值要小於 900 bytes，而 account name, table name 與 key property name 三者加總的長度也不能超過 900 bytes。
7. 在 Development Storage 的 Table Service，每一列的長度不可以超過 1MB。
8. 在 Windows Azure Storage 中，每個 entity transaction group 的批次大小最大是 4MB，但在 Development Storage 中不會檢查這件事。
9. 在 Development Storage 的 Table Service 若查詢表格中不存在的欄位，會回傳錯誤，但在正式的 Windows Azure Storage 不會回傳錯誤。
10. 在 Development Storage 的 Table Service 中，以 Edm.Guid 與 Edm.Binary 為型別的屬性，只支援 eq (=) 和 ne (!=) 運算。
多了解 Development Fabric 與 Development Storage 本身以及它們與正式環境間的差異，可以有效的消除一些因兩者差異而造成的設計瑕疪或問題。
參考資料：
About Development Fabric: http://msdn.microsoft.com/en-us/library/dd179455.aspx
About Development Storage: http://msdn.microsoft.com/en-us/library/dd179339.aspx