發行項
04/14/2015

本文章是由機器翻譯。

.NET Core Framework

.NET Framework 讓您在不同平台間暢行無阻

大多數開發人員更喜歡寫他們的業務邏輯代碼一次以後重新使用它。這是一個更容易的方法比建造不同的應用程式，以面向多個平臺。有關.NET 核心的最近公告 — — Microsoft.NET 框架元件化的版本 — — 和密切的夥伴關係，微軟和 Xamarin 的意思是如果您創建可移植類庫（PCLs）與.NET 核心相容，你比你曾經過更接近這一現實。

什麼關於你現有的.NET 框架庫，儘管嗎？它將使這些跨平臺相容，並將它們轉換為 PCLs 多少工作？輸入.NET 可攜性分析儀。使用幾個簡單的技巧，並且製作一些專案檔案更改，這可能有助於緩解這一進程。

.NET 可攜性分析器工具是由.NET 框架團隊創建一個Visual Studio擴展。你可以使用它與任何新版本的支援擴展的Visual Studio。可攜性分析儀只是指向您的程式集或專案和工具提供摘要、詳細的報告和建議有關的 Api 您應使用來提高相容性。對於專案，該工具列出的錯誤訊息，並將您帶到您需要更改的程式碼。該工具還提供結果對於關鍵 Microsoft 平臺，和你可以將它配置為為單聲道和 Xamarin 等其他平臺提供的結果。

.NET 可攜性分析儀具有調用 API 的可攜性分析儀的主控台應用程式同級（您可以下載它在 aka.ms/w1vcle），生成與可攜性分析器產生相似的結果。對於本文，我將重點介紹利用Visual Studio擴展。它也是重要地注意在撰寫這篇文章時，可能有一些對.NET 可攜性分析器擴展之間的更新和其發佈日期，所以該工具的外觀可能會有所不同從你在這裡看到的圖像。

獲取或設置成功

對於跨平臺成功地採取一個庫，它應該很好考慮並包含主要的業務邏輯。UI 代碼應分成的其他專案。然而，因為，.NET 核心是.NET 框架的一個子集，即使您的代碼很好考慮到您的庫可能使用.NET 核心中不受支援的 Api。

在某些情況下，完成同樣的事情有替代 Api。在這些情況下，可攜性分析儀將建議一個替代的 API。在其他情況下，沒有東西可以代替，你需要分析出特定于平臺的代碼。最後，即使你有沒有程式集考慮如何很好的主意，你可以使用可攜性分析器進行快速評估。

要使用擴展時，您需要Visual Studio2013年或 2014 年。下一步是安裝擴展。你可以通過搜索.NET 可攜性分析儀Visual Studio庫中找到它，或者直接轉到 aka.ms/lah74y。

按一下下載按鈕並選擇打開。下一個對話方塊允許您選擇的Visual Studio要應用擴展的版本。啟動安裝程式的安裝，請按一下，然後關閉關閉對話方塊。現在您可以選擇您的目標平臺來分析程式集或專案。

選擇您的目標平臺

可攜性分析器提供了.NET 框架，ASP.NETvNext （aka.NET 核心），Windows 和 Windows Phone 在預設情況下的結果。您可以通過從工具訪問.NET 可攜性分析儀條目指定附加選項 |Visual Studio和選擇的平臺設置中的選項功能表你想要的目標，如中所示圖 1。

圖 1 為您的專案選擇目標平臺

運行的可攜性分析器

有兩種方法，您可以分析您的程式集和專案：

程式集位置，要分析已生成程式集或可執行檔，從Visual Studio和流覽中的分析功能表訪問的可攜性分析儀。使用此選項，該工具將生成摘要和詳細的報告。
要分析的專案，請按右鍵目標專案在解決方案資源管理器中。選擇分析 |分析程式集的可攜性（見圖 2），這是特定于您所選的專案。使用此選項，該工具生成的摘要，一份詳細的報告，並輸出一條消息到錯誤清單，它提供一個檔案名和行號出現問題的位置。您還可以按兩下每個消息和工具導航到指定的程式碼。

圖 2 選擇分析某一特定專案程式集的可攜性

若要測試該工具，我打開大約一年前已經著手一個專案 — — Windows Phone Silverlight 8 為目標的一種文字遊戲。我開始與我的業務邏輯在可擕式類庫 (PCL) 針對 Windows Phone 8 和 Windows 8。這個想法就是重用庫為 Windows 執行相同的應用程式。然而，我跑進一些問題，是在趕時間，所以我改變了我的方法和我的圖書館現在的目標只有 Windows Phone Silverlight 8。

我的計畫是分析圖書館的可攜性，進行必要的代碼更改，然後將該專案轉換為 PCL 專案並然後它重新開機在 Windows 8.1、 Windows Phone 8.1 和 Windows Phone Silverlight 8.1。我也想要測試它與.NET 核心的相容性。可攜性分析儀給了我一眼上班我需要去做而不需要實際轉換專案，改變目標試圖整理出編譯錯誤。我也好奇地想看看是否我可以使用我的圖書館打造 Android 的應用程式，所以我已經配置了 Xamarin.Android，以及提供結果的工具。

我運行該工具，結果是令人鼓舞的。圖 3 顯示的摘要和詳細的報告、錯誤訊息和報表 URL。根據摘要，我可以看到我的圖書館是相當相容跨所有平臺。它是 100%相容 Windows Phone Silverlight 8.1，這並不奇怪，考慮到 Windows Phone Silverlight 8 原來的目標。

圖 3 詳細的相容性報告顯示相容的平臺

詳細結果類似于試算表顯示的一個或多個我目標平臺不支援的 api。細節很容易就可以掃描。它們標有一個紅色的 X 向英蒂不支援的 API 的美食和綠色的核取記號，以指示支援。它是重要的地注意到 Api 支援跨所有平臺上，因此不需要任何的重構，不會列出在本報告中。

細節還包括一個建議的更改列，我指向將跨多個平臺工作的替代 Api。底部的詳細資訊，該報告包括摘要連結回。這導航回頂部的摘要。我的成績是很短，但對於較長的報表，此"返回頁首"功能很有用。

因為我已經分析了一個專案，我的報告包含錯誤清單消息，以表明該檔和行號出現使用率的問題。如果按一下該消息，該工具將我的檔和消息所表示的行。

如果你想要訪問外Visual Studio結果，它們存儲在一個 HTML 檔案（ApiPortabilityAnalysis.htm) 位於目的程式集相同的專案目錄。位置是英蒂在 URL 中的複雜節頂部的報告，如中所示圖 4。

圖 4 的可攜性分析結果為Visual Studio以外的訪問存儲

進展中的工作

.NET 可攜性分析儀，其結果和指導預計將改變，因為.NET 團隊會收集更多的資訊（見圖 5)。團隊收集有關 API 使用匿名資料，當您使用該工具或對應的主控台應用程式，它總結了 bit.ly/14vciaD。

圖 5 本網站顯示.NET API 使用水準

此網站預設顯示您需要的大多數代碼更改的 Api。您可以通過更改顯示下拉清單（未顯示在圖像中）中的值來更改此。此外可以將滑鼠懸停在"R"或"S"圖示並看到相同的可攜性分析儀所示的代碼建議。

清單中的每個 API 名稱是一個連結，將您帶到報告在哪個平臺上支援的 API 的網頁。該小組打算繼續更新網站，將希望打開它客戶貢獻，所以定期檢查。

以圖書館跨平臺

現在正是時候要修復我的圖書館。我知道我想要我的圖書館能夠與 Windows Phone 8.1 和 Windows 8.1 觀望的幾個問題。不同的方法會替每個問題了。

使用平臺抽象層有兩個資源流相關條目。根據該報告，這些 Api 不支援 Windows 8.1 或 Windows Phone 8.1。該工具不推薦任何 API，我可以替換，得要從我的庫中刪除該代碼。報告告訴我在相同幾行代碼，載入靜態字典檔中使用這兩個成員：

WordList = new ObservableCollection<string>();
StreamResourceInfo info =
  Application.GetResourceStream(new
  Uri("/WordLibWP;component/US.dic", UriKind.Relative));
StreamReader reader = new StreamReader(info.Stream);
string line;
while ((line = reader.ReadLine()) != null)
{
  WordList.Add(line);
}
reader.close();

我知道我可以使用 Windows.Storage Api 上 Windows 8.1 和 Windows Phone 8.1 載入資源檔中，但是然後我的圖書館不會與 Windows Phone Silverlight 相容。為了盡可能多的我決定抽象這段特定于平臺的代碼。平臺抽象層是一個有用的技術，提供一個庫，它定義的行為，但在特定于平臺的代碼中以不同的方式實施這種行為。如果您希望您的代碼能夠跨平臺相容，它是一種技術，您應該熟悉。

這裡是我才執行該操作的基本步驟：

在跨平臺庫中定義的行為：為了做到這一點，我創建了一個抽象類別中的定義的方法，以便讀取詞典檔的庫。我還定義了一個屬性，是我的 DictionaryReader 類的一個實例。這樣的事情：

public abstract class DictionaryReader
{
  public abstract Task<ObservableCollection<string>>
    ReadDictionaryAsync(string path);
  public static DictionaryReader Instance { get; set; }
}

在特定于平臺的代碼中實現的行為：若要做到這一點，我從 Windows Phone Silverlight 專案中的 DictionaryReader 類派生。我公司提供的載入和讀取字典檔作為一種應用程式資源的 ReadDictionaryAsync 方法執行。請注意此代碼本質上是在我的庫中，與一些錯誤檢查資源路徑上，正如我需要為上班我電話代碼的特定格式的代碼相同。我對其他平臺的實現將取決於用於讀取應用程式本地資源，為這些平臺技術不同。然而，與抽象我已經添加了 — — 如中所示圖 6— — 這不應該是一個問題。
初始化庫定義的實例，對平臺 — —具體實施：要做到這一點，我將代碼添加到應用程式類為我的 Windows Phone 專案。這段代碼初始化讀取的檔，作為一種資源我電話具體執行 DictionaryReader 的實例。又在此基礎上，這段代碼是我的特定于平臺的專案中，不在專案中分析：

public App()
{
  DictionaryReader.Instance = new DictionaryReaderPhone();
...
}

圖 6 電話執行載入和讀取詞典

class DictionaryReaderPhone : DictionaryReader
{
  public override async Task<ObservableCollection<string>>
  ReadDictionaryAsync(string resourcePath)
{
  ObservableCollection<string> wordList =
    new ObservableCollection<string>();
  StreamResourceInfo info =
    Application.GetResourceStream(new Uri(resourcePath,
    UriKind.Relative));
  if (info == null)
    throw new ArgumentException("Could not load resource: " +
      resourcePath +
      ". For Windows Phone this should be in the
      Format:[project];component/[filename]");
  else
  {
    StreamReader reader = new StreamReader(info.Stream);
    string line;
    while ((line = await reader.ReadLineAsync()) != null)
    {
    wordList.Add(line);
    }
    reader.Close();
    return wordList;
    }
  }
}

為另一個示例，演示如何抽象出平臺 — —特定代碼，請參見 MSDN 庫文章"平臺抽象與可擕式類庫，"在 aka.ms/q4sq7l。

使用不同的 API 我下一步，評估得到的目前範圍性名稱的條目。我按兩下錯誤訊息，併發現該方法：

public string CheckLanguage()
{
  return Thread.CurrentThread.CurrentCulture.Name.Split('-')[0];
}

根據分析儀可攜性，我可以使用 CultureInfo.CurrentCulture。因為 CurrentCulture 是 CultureInfo 靜態屬性，提供相同的資訊，我正從當前執行緒，它應該工作只是正常。我替換依賴越來越用下面的代碼使用 CultureInfo 執行緒類的代碼：

public string CheckLanguage()
{
  return System.Globalization.CultureInfo.CurrentCulture.Name.Split('-')[0];
}

目前為止，一切都好

我測試我的變化，一切看起來很好。接下來，我重新運行的可攜性分析儀。我的報告是乾淨的只有少量代碼改動，如中所示已經除了我原來的平臺目標，拿起了支援 Xamarin.Android 圖 7。

圖 7 重新運行分析報告後的代碼更改

我跨平臺轉換的最後一步是將庫專案從手機特定庫專案轉換為 pcl 語言從多個應用程式都可以引用。起初，我以為最簡單、最快捷的辦法做到這一點要"就地"轉換，通過手動修改專案檔案。

做一些研究，並且嘗試的一些步驟之後，我發現，我得出的結論有沒有明顯的優勢，手動修改專案檔案。我核實與.NET 團隊的成員，他同意了。很多的説明，你會發現手動修改專案假設某些起始點。

取決於您的專案歷史和你所做的任何其他升級，你可以結束一個破碎的專案。很可能你需要花時間嘗試手動將它轉換後創建一個新的 PCL 專案。此外，即使您手動轉換後的專案開始工作，可以打破如果你以後進行其他更改。

因此，我創建了一個新的 PCL 專案，並建議你這樣做。我複製我的代碼檔到新的專案。一旦我複製該代碼，但得到由於使用語句不再適用于新的 PCL 抱了幾個編譯錯誤。我刪除了這些，我的圖書館準備去。我打開我的 Windows Phone Silverlight 應用程式若要引用我新的 PCL 我的應用程式並再次運行。

試試看

使用可攜性分析儀不僅説明我快速評估的要做才能讓我的圖書館跨平臺的但識別美化任何特定于平臺的我到方法調用和屬性用法的代碼中出現的問題。這也使得 API 建議替代的地方。

我也已經給你們技術分解出特定于平臺的代碼。我新的可攜性分析儀結果表明我的圖書館將在其他的平臺，我想要的目標，以及 Xamarin.Android 上運行。終於能夠創建新的目標新的 PCL 和從我現有的應用程式中引用此 PCL。新的.NET 可攜性分析器將説明您把您的庫帶到新的平臺。

Cheryl Simmons 10 多年一直是微軟的程式設計作家，並已致函有關.NET 基礎類庫，Windows 表單、Windows Presentation Foundation、 Silverlight，Windows Phone 和相關的工具。

感謝以下的微軟技術專家對本文的審閱：Matt加爾佈雷斯，Daniel Plaisted 和泰勒索斯威克