將 WPF 和 Microsoft Silverlight 移植到 WinRT

如果您熟悉 Windows Presentation Foundation (WPF)、「傳統型」Silverlight 或 Windows Phone Silverlight 這類其他的 XAML 架構平台,您便可以重複使用這些技巧來建立 Windows 市集應用程式。本主題列出從原始 WPF 或 Silverlight 應用程式移轉程式碼和 XAML 時應注意的概略差異。

注意  如果您要移轉使用 XAML 的 Windows Phone 應用程式,請參閱適用於 Windows Phone 開發人員的資源

藍圖:這個主題與其他主題的相關性?請參閱:使用 C# 或 Visual Basic 建立 Windows 執行階段應用程式的藍圖

移植 XAML 與程式碼的一般技術

假設,如果您要移轉的程式碼與 XAML 是您先前針對其他 UI 架構 (例如 WPF 或 Silverlight) 所撰寫的程式碼與 XAML,那麼其中涉及的移轉步驟,將遠多於在相同架構中更新不同版本的步驟。儘管如此,您可以使用這個主題來識別 API 與程式設計模型的差異處,以便重複使用部分程式碼與 XAML。最好的方法就是將這些部分整合為程式碼與 XAML 結構,而您可以從使用 C++、C# 或 Visual Basic 的 Windows 市集應用程式的 Microsoft Visual Studio 新專案範本中,取得這些程式碼與 XAML 結構。這樣一來,您就能為 XAML 頁面取得適當的瀏覽結構,以及針對程式碼後置所含的 Windows 執行階段命名空間。如果您需要更多 XAML 頁面或更多程式碼,請使用 [新增] 選項,從 Windows 市集應用程式頁面或程式碼檔案開始,接著以片段方式將原始 XAML 或程式碼複製到新的頁面/檔案,然後視需要進行程式行轉換。

這個主題的其他小節涵蓋了初始 UI 架構與 Windows 市集應用程式都很常見的各種功能層面。請詳讀每一小節,概略了解其中的差異,以及了解要如何做才能讓移轉的 XAML 與程式碼適用於 Windows 市集應用程式。

新設計與行為

Windows 市集應用程式擁有獨特的外觀和行為 (特質),與那些使用其他 XAML 架構平台所建立的應用程式有所不同。請務必花些時間了解建立最佳 Windows 市集應用程式的最佳做法。解決建立 Windows 市集應用程式的設計問題時,通常表示您需要重新編寫大量 UI。尤其是,為了要遵循設計指導方針,您可能必須重新編寫對話方塊、功能表、輸入命令及清單的處理方式。請參閱建立出色的 Windows 市集應用程式適用於 Windows 市集應用程式的 UX 指導方針

應用程式物件與應用程式模型

  • 因為應用程式可以暫停和繼續執行,所以啟動的應用程式模型應與應用程式週期的模型不同。如需詳細資訊,請參閱啟動、繼續及多工處理
  • app.xaml 中的 Application 標記不能用來附加應用程式週期事件;Suspending 這類事件的事件觸發必須在 app.xaml 程式碼後置檔案中的啟動邏輯完成。
  • 從 Microsoft Win32 程式設計的角度來看,Window 物件很少會正好相當於執行中的應用程式 HWND。某些進階的視窗功能會出現在不同的物件,您可以透過 Window.CoreWindow 屬性的值取得。
  • 從另一方面來說,如果您從 Silverlight 應用程式的角度來看,不再有瀏覽器主機做為中繼程式設計界限:您的 Windows 市集應用程式會直接在 Windows 執行階段執行。移除 Silverlight 要處理的瀏覽器主控問題,例如通過程式存取層的輸入處理、受限制的存放裝置存取,以及網際網路為中心的安全性和快取模式,可以簡化許多程序。
  • Silverlight 應用程式可以封裝應用程式組件做為部署套件、做為外部組件,或者做為依需求下載的元件。Windows 市集應用程式也有這些選擇,但是用來存取套件的 API 則有所不同。Silverlight 使用 Application.GetResourceStream,而 Windows 市集應用程式使用更一般化的模型,安裝的套件就只是一個儲存資料夾。例如,您可以取得 Package.InstalledLocation 屬性值,然後呼叫各種不同的 StorageFolder API (大部分是非同步),以取得任何其他的封裝元件。如需詳細資訊,請參閱建立及擷取 Windows 市集應用程式中的資源
  • Windows 執行階段應用程式模型使用一種功能概念。您必須在開發和部署程序中宣告功能,使用者才能在 Windows 市集 UI 看到您應用程式要求的特定功能。您可能需要要求功能,才能存取使用者的媒體櫃儲存區、使用網路攝影機 API 等等。之前可在 Silverlight 和 WPF 使用的特定程式碼,即使您在語法層級正確轉換程式碼,仍然需要要求 Windows 執行階段功能才能存取該程式碼。如需詳細資訊,請參閱應用程式功能宣告
  • 從磚直接啟動應用程式不是啟用 Windows 市集應用程式的唯一方法。例如,您的應用程式可能要支援透過檔案關聯、「播放至」協定等啟動。為了規劃這一點,您應該讓應用程式狀態持續保持為應用程式資料,並確認您的應用程式擁有所有啟用可能情況所需的所有啟動資料。如需詳細資訊,請參閱如何啟用應用程式,以及啟動、繼續及多工處理中的其他主題。

.NET 程式設計和類型投影

Windows 執行階段架構的基礎原則是,開發人員可以使用不同語言來存取相同的基本 Windows 執行階段功能和概念。每一種不同的語言都能存取 Windows 執行階段,卻又能保留語言特色或模式的方法,都是透過「類型投影」來達成。以 Microsoft .NET 語言為例,那些語言的開發人員熟悉 .NET 類型系統、基本類型以及 .NET mscorlib 組件執行概念。

針對 Windows 執行階段進行程式設計時,有特別針對 .NET 投影的類別清單。這些類型存在於 mscorlib 組件或 System 命名空間,或者具體地新增到 WindowsRuntime 組件其中之一,做為 Windows 執行階段程式設計的 .NET 參考組件。

  • 一般收集介面投影為 .NET 程式設計人員熟悉的收集介面。IVector<T> 投影為 IList<T>IMap<K,V> 投影為 IDictionary<TKey,TValue>。透過 System.Linq 列舉類型支援 foreach 語法與相關的擴充方法。相關檢視類別和唯讀變數也有類似的投影。透過這些投影,任何執行收集介面的 Windows 執行階段類別,都可以支援投影的 .NET 收集介面的 API。

  • Uri 投影為 System.Uri。 (然而,這其中有一些值得注意的差異;請參閱「URI」區段)。

  • 一般「基本類型」投影為開發人員熟悉的 .NET 程式設計的 mscorlib/System 類型。例如,所有使用 double 值的應用程式程式碼都可以在以 .NET 語言進行程式設計時使用提供的 System.Double API。

  • 與類型系統互動的 .NET API 可以參照 .NET System.Type,而且您可以在 Windows 執行階段程式碼中使用 typeof 運算子(請注意:如果您執行互通性,或在部分程式碼中使用 C++,C++ 雖然有 typeid 運算子,但與 typeof 相比功能有限)。

  • IReference<T> 會針對 .NET 投影為 Nullable<T>,並啟用例如 bool? 等語言語法來代表可為 null 的布林值。

  • EventHandler<T> 會針對 .NET 投影為 System.EventHandler<TEventArgs>

  • HResult 會針對 .NET 投影為 System.Exception。另外也支援以 API 為單位從 Windows 執行階段錯誤擷取訊息資訊,並為 .NET 開發人員提供以 System.Exception 為基礎的適當類型例外。您可以使用 try-catch 和類似的技術來處理例外狀況,而且可以處理您已經熟悉的許多標準 .NET 例外狀況。如需詳細資訊,請參閱以 C# 或 Visual Basic 撰寫之 Windows 執行階段應用程式的例外狀況處理

  • ICommand 模式使用 .NET 定義 (System.Windows.Input.ICommand)。
  • 當您使用物件做為 Windows 執行階段資料來源時,為 .NET 中撰寫的繫結感知商業物件使用的介面會進行轉譯。例如,在商業物件類別 (原本是針對 WPF 或 Silverlight 撰寫的類別) 實作時,繫結可回應 PropertyChangedCollectionChanged

  • 一般用來做為 XAML UI 程式設計值類型的結構,有許多會投影為有可用公用程式方法的結構。這些結構的名稱與命名空間位置相同,但是參考 WindowsRuntime 組件,所以公用程式方法會支援 .NET。例如,.NET 程式設計人員可以使用 Matrix3D 的公用程式 API,例如 HasInverse 或內建運算子 (C++/CX 也為其結構提供一些公用程式支援,也是做為投影實作,但該支援的功能較少)。

  • 一個相關的概念:一旦類型投影為 .NET 類型,就可以支援 .NET 延伸方法。這樣可以將 .NET 延伸方法提供給 Windows 市集應用程式程式設計專用。例如,現有的 .NET 類型 (如 StreamReader) 可以支援使用與 Windows.Storage API 類似之 async 模式的方法。

  • 所有執行階段物件的基本類型都會顯示為 System.Object,且擁有預期的 System.Object API,例如 ToString。不過,在 Windows 執行階段中執行這些方法的實作時,可能會有些許差異。.NET 參考文件通常會明顯標示這些差異 (在 Windows 執行階段的附註小節)。
注意  類型投影的目的是要協助您移轉 XAML 和程式碼,特別是當您移轉 XAML 頁面、商業物件或獨立運作之邏輯類別的程式碼後置時。在多數情況下,您不需要調查您原始程式碼中的類型是否真的是 Windows 執行階段中的投影型別。編譯器和投影範本會幫您把事情做好。

當您使用投影的類型時,對於不屬於 .NET 核心架構程式庫且未在現有 .NET 命名空間 (例如 System.Collections.Generic) 中定義而為了支援執行階段提供的投影,您可能仍需要命名空間參考。例如,如果您有使用 Point 結構的 C# 程式碼,您仍需要參考 Windows.Foundation 命名空間的 using 陳述式,因為投影的 Point 也是如此定義。

如需使用 C++、C# 或 Visual Basic 程式設計的 .NET 與 Windows 市集應用程式的詳細資訊,請參閱適用於 Windows 市集應用程式的 .NET 概觀

一般程式設計模型

  • 如果您不是使用 .NET 語言設計程式,而是使用 Visual C++ 元件延伸 (C++/CX) 設計程式,許多結構使用基本 C 樣式定義且不支援非資料成員。
  • 程式設計模型已整合非同步作業的語法。非同步作業在程式設計模型中比在 WPF 或 Silverlight 更普遍。非同步 API 的目的是強化模式,使其較不會在事件處理常式或回呼中意外封鎖 UI 執行緒。如需詳細資訊,請參閱快速入門:在 C# 或 Visual Basic 中呼叫非同步 API
  • 由於非同步模式或是其他不在 UI 執行緒上的背景工作,您可能需要從其他執行緒進行呼叫,以便最後以非同步方式更新 UI 執行緒。您用以跨越執行緒 (通常從背景執行緒到 UI 執行緒) 的 API 和在 Silverlight 中相同,亦即 DependencyObject.Dispatcher
  • 過去使用 mscorlib 及 system 組件 API 完成的檔案和儲存存取,現在則是使用專用的系統 API (例如 StorageFile) 來完成。
  • 如果您使用 .NET 語言設計程式,您也可以使用現有的 System.IO.Stream 基礎邏輯。您可以存取從類似的 Windows 執行階段類型傳回串流的延伸方法,例如在 IRandomAccessStream 執行個體上呼叫 AsStream 延伸方法。在程式碼編輯器中,每當您從相關的串流/緩衝區類型獲得 Stream 執行個體時,System.IO.Stream API 會顯示為 Microsoft IntelliSense 下拉式清單的選項。

瀏覽

Silverlight 瀏覽模型使用 XAML 頁面 (鬆散或套件),做為找出瀏覽內容目標的基礎。Windows 市集應用程式則是使用類型,尤其是 XAML 頁面中代表 x:Class 的類型。最好的方法是使用 [方案總管] 的 [新增] 功能,在您選擇的 Windows 市集應用程式專案範本中建立新的 XAML 頁面。匯入原始 Silverlight 頁面根層次下方的元素,再解決任何可能存在的轉換問題。接著使用主頁面上的 Frame 建立您的瀏覽結構。或者,使用 [格線應用程式] 或 [分割應用程式] 範本建立新專案;這些範本包含已有瀏覽架構的頁面,以及檢視狀態範本和暫停/繼續邏輯。您也可以使用 [中樞應用程式] 範本和瀏覽策略。如需詳細資訊,請參閱第三部分:瀏覽、配置與檢視新增頁面控制項

Windows 執行階段在預設控制組中具有 PageFrame 類別,而在 Silverlight 中,這些類別來自於 SDK 程式庫,而且必須加以散佈。如果您移轉的 XAML 含有 PageFrame,您可以從元素中移除 "sdk:" 前置詞和 "sdk:" 前置詞的 xmlns 對應。在瀏覽動作期間,如果頁面需要進行任何清除工作,可以覆寫 OnNavigatedToOnNavigatedFrom。不過 Frame 類別中也有可用的事件和覆寫,例如 Navigated,因此您可以考慮將瀏覽邏輯置於 Frame 中,而非單獨頁面中。 此外,Silverlight Frame 在其控制項範本中有簡單的瀏覽按鈕,而 Windows 執行階段瀏覽功能則已與頁面範本整合並針對按鈕本身使用專用樣式和範本。如需詳細資訊,請參閱快速入門:在頁面之間瀏覽

磚和通知

在先前的 XAML 架構中,磚和通知功能有各種支援層級,因而尚無轉換這些支援的一般方法。如需這些功能在 Windows 市集應用程式中如何運作的詳細資訊,請參閱使用磚、徽章以及快顯通知。如果您的應用程式使用 Windows Phone 推播通知,請參閱適用於 Windows Phone 開發人員的資源

使用 .NET 架構

針對使用 NET 語言 (C# 或 Microsoft Visual Basic) 的 Windows 市集應用程式,您呼叫的 .NET Framework API 是特定 .NET Framework 設定檔的一部分。這個關係將會在適用於 Windows 市集應用程式的 .NET 概觀主題中詳細說明。

XAML 語言功能

Windows 執行階段 XAML 與 Sliverlight XAML 就屬於 XAML 語言本身的功能而言很相似,與 WPF XAML 也是不相上下。不過還是有少許差異。

  • 您使用 using: 辨識符號,而不是使用 clr-namespace:/assembly= 辨識符號,設定「程式碼到 XAML」命名空間參考。XAML 命名空間不再參考特定組件,所有組件資格和內容物都是由應用程式模型和應用程式套件的撰寫方式處理。
  • 因為您不能對應特定組件,因此有些針對 mscorlib 建立以支援通用語言執行階段 (CLR) 基元的參考資料不再發生作用。請改用 XAML 語言內建類型,例如 x:String。如需詳細資訊,請參閱 XAML 內建資料類型。您之前在 ResourceDictionary 中儲存為 x:String 的許多字串,最好也請考慮將字串儲存在專案的資源檔案中。如需詳細資訊,請參閱全球化應用程式
  • Windows 執行階段 XAML 不支援自訂標記延伸。
  • 在少數情況下,含有 Silverlight 可接受的無首碼 Name 屬性的 XAML 可能需要改用 x:Name 屬性
  • Setter.Property 過度限制卻可用於 Silverlight XAML 的一些案例,將無法在 Windows 執行階段 XAML 使用。大部分的 Setter.Property 值應只是簡單的相依性屬性名稱,而且不會嘗試限定其擁有者 (附加屬性例外,您仍應限定那些屬性的擁有者)。
  • 如果您從 WPF 移轉 XAML,除了已列出的 Silverlight XAML 差異之外,還有 Windows 執行階段 XAML 不支援的建構。這些包括:DynamicResource 標記延伸 (及基礎資源查詢行為)、x:ClassModifierx:Subclassx:Array 與相關的 XAML 2009 泛型支援、x:Codex:Static、明確使用的 x:Type (針對需要的內容,會有隱含的 x:Type 評估)、範本中的 VisualTree 節點,以及其他細微差異。您應該可以在設計階段根據 XAML 剖析例外來找出任何 XAML 相容性問題。

觸控與輸入

  • 沒有特定滑鼠輸入事件,例如 MouseLeftButtonDown。 這些事件與觸控輸入特定事件整合於 Pointer 事件中。在大部分情況下,您可以將相關滑鼠事件轉換為 PointerPressedPointerReleasedPointerEnteredPointerExited。如需詳細資訊,請參閱回應使用者互動。如果是 MouseWheel,請使用 PointerWheelChanged 事件。您可以從事件資料中,在主要 PointerPointPointerPointProperties 中找出滾輪差異。
  • 如果您正在處理原始操作以啟用控制項中的動作,而且已建立可用於操作處理的視覺狀態,您應該確認正在使用的控制項尚無內建的操作或手勢支援。例如,Windows 執行階段 ListBox 已啟用數種進行佈景主題轉換時的互動。
  • 就互動總體而言,請考慮處理手勢事件,而非指標事件,因為前者通常比較容易。例如,針對 Silverlight 中使用滑鼠特定事件處理的互動,在 Windows 執行階段事件模型下使用 Tapped 事件處理通常是比較好的。
  • 使用屬性可以元素為單位啟用或停用特定觸控互動功能。例如,您可設定 IsRightTapEnabledfalse,該元素就不會引發 RightTapped 事件。這是為了避免在事件透過控制項組合視覺化樹狀結構反昇時可能發生的手勢和操作辨識問題。
  • 按鍵事件的鍵值沒有 PlatformKeyCode / Key 分別。從事件資料報告的鍵值,使用不同列舉 VirtualKey,而且其他鍵值事件資料可以從 KeyStatus 取得。
  • UIElement 的指標擷取可以擷取多個指標,以支援啟動擷取的觸控操作。若要取得正確的指標參考,請使用指標相關事件資料類別,例如 PointerRoutedEventArgs
  • Control.Focus 的呼叫應指定列舉值,說明該焦點動作是以程式設計方式進行。Windows 執行階段會區分焦點呼叫,因為其視覺狀態會在程式設計焦點呼叫使用不同的行為。您可能必須在範本中針對非鍵盤焦點新增自訂的視覺狀態。
  • 某些 Windows 執行階段控制項具有內建的操作處理。例如,ScrollViewer 會在內部處理捲動、移動瀏覽及縮放互動,讓控制項能夠提供適當的動作回應。控制項的處理可以防止觸發低階指標事件。您可以呼叫 CancelDirectManipulations 來覆寫這個行為。不過您也可能想要從頭到尾檢視您控制項的輸入處理。或許已經有內建的行為涵蓋了您的情況,若是如此,則不再需要指標層級處理常式。

圖形和元素配置/組合

  • 為了最佳化新圖形堆疊功能的元素組合,我們去除了某些會拖慢轉換的 API/概念。範例包括 OpacityMask、非矩形短片、自訂 Easing 函式以及點陣圖效果。
  • Windows 執行階段不支援 VideoBrushRadialGradientBrush
  • Windows 執行階段映像 API 擁有不同且功能更強的基礎影像處理元件,也就是 Windows 影像處理元件 (WIC)。好消息是這個元件可以比 Silverlight 或甚至是 WPF 支援更多的映像來源格式。您還可以使用容易使用的編碼器和解碼器類型,以及一些已內建於 WIC 可用來操作映像的其他 API。如需詳細資訊,請參閱 Windows.Graphics.Imaging 命名空間。
  • BitmapCache 有不同於 Silverlight、Silverlight for Windows Phone 或 WPF 中的基礎邏輯。同時,點陣圖快取可以和動畫有相互關係,可能會導致某些動畫被視為相依。如果您使用 UIElement.CacheMode,應該要重新設定應用程式的設定檔,並重新思考在部分 UI 使用 UIElement.CacheMode 設定對 Windows 市集應用程式而言是否能增強效能。如需詳細資訊,請參閱 UIElement.CacheModeDebugSettings.IsOverdrawHeatMapEnabled
  • 針對使用 WriteableBitmap 的某些情況,最好可以改用 RenderTargetBitmap

控制項

  • Windows 市集應用程式與其他使用 XAML 做為 UI 定義的架構擁有相同的基本控制項,例如 ButtonListBox,以及基本配置容器,例如 BorderGrid 以及 StackPanel。Windows 執行階段也有許多現成的控制項集合,例如 SemanticZoomFlipView。 此外,GridView 是一個獨立的控制項,而不是用於 ListView 的一個元件,且在 GridViewListView 之間唯一真正的差異在於每個使用的已呈現項目的主要方向。如需詳細資訊,請參閱依功能分類的控制項
  • 雖然您使用的控制項,通常會與您在原始 Silverlight 或 WPF 應用程式中使用的控制項相同,甚至將整個 UI 移轉到對應的元件,但這不見得是最適合的方法。當您定義應用程式的 UI 但想要停止並再次檢視 Windows 市集應用程式設計指南時,更是如此。例如,您的原始應用程式及其 UI 中的控制項一開始可能不是針對觸控所設計,但您的 Windows 市集應用程式卻應該一開始就針對觸控加以設計。整體 UI 體驗也將不一樣,因為不再由瀏覽器主控。如需設計的詳細資訊,請參閱設計應用程式的 UX。如需控制項的 UX 指導方針的詳細資訊,請參閱UX 指導方針索引

動畫、轉換、視覺狀態、樣式

  • Windows 執行階段加入了個人特質動畫的概念。這些動畫可以在 XAML 做為轉換動畫和佈景主題動畫直接套用到 UI 元素,不需要針對該元素的多個屬性採取動作。腳本動畫的運作方式幾乎完全相同。然而,並不是所有腳本動畫都預設為啟用。預設停用相依式動畫的目的是為了讓開發人員更加注意動畫對效能產生的負擔,這可能會對主要 UI 執行緒造成嚴重的影響。如果您的動畫沒有如預期般執行,試著將 EnableDependentAnimations 設成 true。但請謹慎使用,因為執行相依式動畫會造成效能的負擔。如需詳細資訊,請參閱讓 UI 產生動畫效果腳本動畫建立流暢的動畫
  • 如果您的視覺狀態 XAML 定義中有任何 "vsm:" 首碼,請移除首碼使用與首碼定義。您不需要再分別對應視覺狀態首碼和命名空間。
  • 如果您要轉換視覺狀態,請確認將 "Mouse" 概念轉換為 "Pointer" 概念,就像變更項目層級事件處理方式一樣。您可以重新命名視覺狀態名稱,以及調整狀態可變更的屬性。看一下 Windows SDK 安裝 include/winrt/xaml/design 子資料夾中的現有 XAML 資源字典,例如 generic.xaml。這些可能針對視覺狀態和相關事件提出一些您可以遵循的模式建議。
  • 如果您轉換過的自訂控制項已有現有的高對比佈景主題,請務必遵循 ThemeDictionaries 模型,將佈景主題連接到控制項定義。尤其是,您可能會想支援 HighContrastScheme 列舉中識別的已命名佈景主題。如需詳細資訊,請參閱 XAML 高對比樣式範例
  • 如果您的應用程式提供佈景主題切換功能,則您的控制項應該同時之支援淺色和深色佈景主題範本。預設範本具備這些,不過您可能需要將佈景主題新增到您匯入的任何自訂範本中。
  • WPF 和 Silverlight 支援使用 Binding 運算式在 Style 中針對 Setter 提供 Value 的功能。Windows 執行階段不支援 Setter.ValueBinding 用法 (Binding 將不會評估,且 Setter 沒有影響,您不會碰到錯誤,但也無法得到想要的結果)。當您從 WPF 或 Silverlight XAML 轉換 XAML 樣式時,請使用字串或設定值的物件來取代任何的 Binding 運算式用法,或者將值重構為共用的 StaticResource 值,而不是 Binding 取得的值。

媒體

  • 媒體 API 大致相似,但是數位版權管理 (DRM) 與媒體 API 整合方式不同。不像 Silverlight,Windows 有可插入的 DRM 模組,而 PlayReady 是幾種可能支援項目之一,所以 API 和負責內容保護管理員有所不同。

  • MediaElement 也大致相同,不過您最好為所有先前的 MediaElement 傳輸控制項範本定義新的 XAML 範本,讓 UI 具有觸控感知功能。或者您可以使用 AreTransportControlsEnabled 取得一些預設的傳輸控制項。值得注意的是,Windows 執行階段新增的 MediaElement API 功能是可以在載入時使用 "poster"、偵測和使用立體視訊封裝模式,以及新增視訊效果。
  • 各平台間的相機擷取功能在概念上非常不同,如果您有此功能,將需要重新撰寫程式碼,而不是轉換程式碼。如需詳細資訊,請參閱如何預覽網路攝影機中的影片以及使用擷取裝置的媒體擷取範例。因為無法使用 VideoBrush,所以您可能要使用 CaptureElement 做為顯示表面。

URI

統一資源識別元 (URI) 在 Windows 執行階段中處理檔案參考工作的方式有些微的不同。不支援相對 URI,尤其是在純 URI 類型的層級。在某些 API 呼叫中,.NET System.Uri 可能會給您一個 RelativeOrAbsolute 選擇,但是實際上所有這類 URI 都是絕對的,而且是按照概念和位置進行評估的,例如應用程式套件、使用者選取的位置、應用程式資料等。

任何使用 URI 的屬性值可能都需要檢查。您不能使用 file: 配置 URI。您可能可以在 XAML 中使用 URI 參照 Image.Source 檔案這類的值,完全不需要擔心 URI 問題,並讓它如新的 Windows UI 一樣運作。但是這取決於原始應用程式的架構方式。在 XAML 指定時,URI 通常會顯示為相對 URI,但是在執行階段設定任何屬性之前,會先透過 XAML 剖析器處理並完成這些字串。若要在程式碼後置重新產生相同的行為,將傳回的 FrameworkElement.BaseUri 當作結合基礎 URI 和相對 URI 之 Uri 建構函式的 baseUri 參數值。如需詳細資訊,請參閱定義應用程式資源

檔案和儲存 API

您在 Windows 執行階段中用來存取檔案和存放裝置的技術與 .NET 中使用的技術相當不同,尤其是這些 API 很多都使用非同步模式與 async/await 關鍵字。如需詳細資訊,請參閱存取資料和檔案

XML 和 XMLDOM

使用 C++、C# 或 Visual Basic 的 Windows 市集應用程式可使用的 .NET 區域,不包含架構中的部分 XML DOM API,或是將部分基底類型轉送給 Linq 命名空間。在 Windows.Data.Xml.DomSystem.Xml.Linq 找尋類似的 API。

裝載與並列 HTML

對於 Silverlight,並列 HTML 是很直接的,因為 Silverlight 控制項裝載在 DOM 元素內,而其他 HTML 內容則是在其他 DOM 元素或 iframe 內。或者對於 WPF,您或許已使用了 WebBrowser 控制項。針對使用 XAML 做為 UI 的 Windows 市集應用程式,用來進行 HTML 內容顯示的控制項是 WebViewWebView 模型是 HTML 顯示於整體 XAML UI 內部的一個區域。您在 Windows 市集應用程式中顯示的 HTML 內容不需要針對使用者經驗的原因和安全性的原因進行檢查。請不要只是將您在 Silverlight 應用程式 iframe 中的內容重新定位為 WebViewSource。您也必須檢查哪個邏輯應該要保留為 HTML 的 JavaScript 程式碼,而不是當成頁面的程式碼後置來執行。Windows 執行階段在 WebView 界限內處理使用者互動事件的方式,會影響您在此處的決定。如需詳細資訊,請參閱 WebView

轉換專案

一般而言,轉換整個專案最好以 Windows 市集應用程式的一個現有專案範本開始。接著在 [方案總管] 使用現有的 [加入] 功能,導入新的或現有的 XAML 頁面與程式碼後置檔案。最後,再將特定程式碼區塊移轉到 XAML 和程式碼檔案。如果這樣做,可以避免意外出現之前架構的實作細節,以及專案和組建的基礎結構。您可以使用 using/Imports 陳述式,搭配正確的 "Windows" 命名空間,參考目前的組建類型,以及存取 .resw 資源系統,因為這些都可以從新範本專案和頁面取得。

如果您的 Silverlight 專案使用以 Binding 為基礎的當地語系化系統,如 使用方法:將 XAML 內容設定為可當地語系化主題所述,應該考慮將當地語系化技術變更為使用在封裝資源索引 (PRI) 系統宣告的字串。以 Binding 為基礎的當地語系化系統仍然可以運作,但它無法像 PRI 與 .resw 檔案提供如此多的工具支援,無論在 Visual Studio 內部或針對任何使用 Visual Studio 當地語系化方法的專用當地語系化處理程序或工具都一樣。

如果您選擇嘗試帶入整個程式碼檔案,則通常可以搜尋和取代 using/Imports 陳述式,或完全合格的參考資料。例如,"System.Windows" 應該以 "Windows.UI.Xaml" 取代。這個 Silverlight/WPF 類型與 Windows 執行階段類型及其命名空間關聯的一般性規則有少數的例外,我們將在 API 文件 (「備註」區段中) 記錄這些案例。

如需專案範本的詳細資訊,請參閱 Windows 市集應用程式的 C#、VB 及 C++ 專案範本

移轉應用程式的其他資源

相關主題

從 Windows Phone Silverlight 移到 WinRT
適用於 Windows Phone 開發人員的資源
使用 C# 或 Visual Basic 建立 Windows 市集應用程式的藍圖
Windows 市集應用程式的 UX 指導方針
Windows 市集應用程式的 C#、VB 及 C++ 專案範本
適用於 Windows 市集應用程式的 .NET 概觀
Windows 市集應用程式與 Windows 執行階段的 .NET Framework 支援

 

 

顯示:
© 2015 Microsoft