|
|
英文原文：C# and Visual Basic on the WinRT API
?。ㄗ髡撸篔onathan Allen 譯者：侯伯薇）
盡管我們可以使用 .NET 語言來調用 Win32 API，但那樣做會很困難。所以在過去的兩年間微軟一直在構建替代的方案，它就是實現了跨語言支持的 Windows 運行時，即 WinRT。我們可以在 C++ 和 .NET 中創建 WinRT 組件，并且可由二者以及 JavaScript 使用。
盡管 COM 在表面上是一種基于 OOP 的框架，但它與 .NET 之間有很大的區別。在 WinRT 出現之前，COM 是基于接口而不是基于類的。這意味著其中缺少很多 .NET 開發者認為應該有的內容，像構造函數以及靜態方法等。C++組件擴展解決了這個問題。
WinRT 形式的 COM 使用的元數據格式和通用語言運行時（Common Language Runtime）相同。這些信息存儲在表示結構的 WINMD 文件中，盡管沒有實現，但在所有公有類中都會有。FXCop 被用于檢驗這些文件所暴露的 API 是否遵循 .NET Framework 的設計指南。
.NET 在最開始時就有“API 設計委員會（API Design Board）”。受此啟發，Windows 運行時也會建立 API 設計委員會來對其進行管理。很多最初的成員都在 .NET 委員會中，并且很多指南都直接來自于 .NET 基本類庫所遵循的原則。
Windows 運行時會返回 HRESULT，而不會拋出異常。對于眾所周知的 HRESULT 值來說，會拋出相應的異常，而對于其他值就只能拋出 COMException。
WinRT 的 IAsyncOperation 接口現在使用新的 async/await 關鍵字，就像 .NET 的 Task 對象一樣。
所有 Windows 運行時的集合接口都被映射到 .NET 框架的等價物上。在 .NET 4.5中添加了 IReadOnlyList 和 IReadOnlyDictionary，用來負責處理 WinRT 中的只讀集合。
WinRT 和 .NET API 在兩個地方無法匹配。WinRT 的 stream 無法直接與 .NET 的 IO.Stream 類兼容，但是可以調用名為 AsStream 的擴展方法來進行轉換。WinRT 還擁有名為 IBuffer 的接口，這在 .NET 中也無法簡單地實現。在此也有一個擴展方法來進行 IBuffer 和比特數組之間的轉換。
我們可以使用 C# 和 VB 來創建新的 Windows 運行時程序庫，過程非常簡單。為了把類暴露為 Windows 運行時組件，我們只需要把項目類型設置為“WINMD 文件”，并確保遵循以下規則：
- API 簽名只使用 Windows 運行時的類型
- 結構體只能擁有公有的數據字段
- 只允許對 XAML 控件使用繼承，其它類型都必須使用 sealed 關鍵字。
- 只支持內建的泛型
編譯這些庫之后，我們就可以在 C++ 和 JavaScript 中調用它們，就像從 .NET 中調用一樣簡單。
警告
由于 WinRT 是基于 COM 構建的，所以你同樣會有引用計數和 mark-and-sweep 垃圾回收器之間無法融合的問題。對于實現了析構函數釋放非內存資源的對象來說，這是最常見的問題。我們可以考慮調用“Marshal.FinalReleaseComObject”來解決問題，但是那本身也存在問題。
COM 風格的 marshaling 需要在 .NET 和本地組件之間調用。盡管這通常是無關緊要的，但是如果 API 非常不正式，那么就會出現問題。
內建的 WinRT 庫（而不是 XAML）是在 Metro 運行時環境之外提供的。然而，第三方的 WinRT 庫并非如此。這是 WinRT 中激活框架（activation framework）的限制，而不是 .NET 的問題。
NET技術：可供C#和Visual Basic調用的WinRT API，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
