Windows Phone Silverlight から UWP への移行します。Move from Windows Phone Silverlight to UWP

場合は、開発者、Windows Phone Silverlight アプリである Windows 10 への移行で、スキル セットと、ソース コードの優れた使用を行うことができます。If you’re a developer with a Windows Phone Silverlight app, then you can make great use of your skill set and your source code in the move to Windows 10. Windows 10 で、ユニバーサル Windows プラットフォーム (UWP) アプリは、これは、顧客がすべての種類のデバイスにインストールできる 1 つのアプリ パッケージを作成できます。With Windows 10, you can create a Universal Windows Platform (UWP) app, which is a single app package that your customers can install onto every kind of device. Windows 10、UWP アプリ、およびアダプティブ コードとこの移植のガイドで説明アダプティブ UI の概念の詳細については、次を参照してください。、ユニバーサル Windows プラットフォーム (UWP) アプリに関するガイドします。For more background on Windows 10, UWP apps, and the concepts of adaptive code and adaptive UI that we'll mention in this porting guide, see the Guide to Universal Windows Platform (UWP) apps.

Windows 10 アプリを Windows Phone Silverlight アプリを移植するときに、遅れされてモバイル機能ができますWindows Phone 8.1 で導入されたを画していますユニバーサル Windows プラットフォーム (UWP) を使用するようにアプリが、モデルと UI フレームワークは、すべての Windows 10 デバイスでユニバーサル。When you port your Windows Phone Silverlight app to a Windows 10 app, you'll be able to catch up on the mobile features that were introduced in Windows Phone 8.1, and go far beyond them to use the Universal Windows Platform (UWP) whose app model and UI framework are universal across all Windows 10 devices. これにより、1 つのコード ベースから、1 つのアプリ パッケージで、PC、タブレット、電話、その他の多くの種類のデバイスをサポートできます。That makes it possible to support PCs, tablets, phones, and a large number of other kinds of devices, from one code base and with one app package. また、これによりアプリの潜在顧客が増加し、共有データ、購入コンシューマブルなどの可能性が高まります。And that will multiply your app's potential audience and create new possibilities with shared data, purchased consumables, and so on. 新機能に関する詳細については、次を参照してください。 Windows 10 の開発者向け新機能についてはします。For more info on new features, see What's new for developers in Windows 10.

場合は、Windows Phone の Silverlight バージョンのアプリと Windows 10 バージョンの両方が使用可能顧客と同時にします。If you choose to, the Windows Phone Silverlight version of your app and the Windows 10 version of it can both be available to customers at the same time.

  このガイドを手動で Windows 10、Windows Phone Silverlight アプリを移植するように設計されています。Note  This guide is designed to help you port your Windows Phone Silverlight app to Windows 10 manually. このガイドの情報を使って、アプリを移植できるだけではありません。移植プロセス自動化支援用に提供された Mobilize.NET の Silverlight Bridge の開発者プレビューを試すこともできます。In addition to using the information in this guide to port your app, you can try the developer preview of Mobilize.NET's Silverlight Bridge to help automate the porting process. このツールは、アプリのソース コードを分析し、UWP の対応する Windows Phone の Silverlight コントロールへの参照と Api を変換します。This tool analyzes your app's source code and converts references to Windows Phone Silverlight controls and APIs to their UWP counterparts. このツールは、まだ開発者プレビューの段階にあるため、すべての変換シナリオを扱えるとは限りません。Because this tool is still in developer preview, it does not yet handle all conversion scenarios. ただし、ほとんどの開発者はこのツールを使い始めることで、時間と労力をいくらかは節約できます。However, most developers should be able to save some time and effort by starting with this tool. 開発者プレビューを試すには、Mobilize.NET の Web サイトをご覧ください。To try the developer preview, visit Mobilize.NET's website.

XAML と .NET、または HTMLXAML and .NET, or HTML?

Windows Phone Silverlight では、Silverlight 4.0 と .NET Framework のバージョンと UWP Api の小さなサブセットに対してプログラムに基づいて XAML の UI フレームワークがあります。Windows Phone Silverlight has a XAML UI framework based on Silverlight 4.0, and you program against a version of the .NET Framework and a small subset of UWP APIs. XAML は、Windows 10 バージョンを選択したのでする知識と経験のほとんどは転送が、ソース コードの多くは高くなりますので、Windows Phone Silverlight アプリでは、Extensible Application Markup Language (XAML) を使用してソフトウェア パターンを使用します。Since you used Extensible Application Markup Language (XAML) in your Windows Phone Silverlight app, it's likely that XAML will be your choice for your Windows 10 version because most of your knowledge and experience will transfer, as will much of your source code and the software patterns you use. UI のマークアップと設計であっても容易に移植できます。Even your UI markup and design can port over readily. マネージ API、XAML マークアップ、UI フレームワーク、ツールはすべて使い慣れたものであり、UWP アプリでは、XAML と共に C++、C#、Visual Basic を使うことができます。You will find the managed APIs, the XAML markup, the UI framework, and the tooling all reassuringly familiar, and you can use C++, C#, or Visual Basic along with XAML in a UWP app. 若干の課題が発生するとしても、そのプロセスの相対的な容易さに驚くはずです。You may be surprised at how relatively easy the process is, even if there is a challenge or two along the way.

C# または Visual Basic を使ったユニバーサル Windows プラットフォーム (UWP) アプリのためのロードマップ」をご覧ください。See Roadmap for Universal Windows Platform (UWP) apps using C# or Visual Basic.

  Windows 10 を補って余りの .NET Framework、Windows Phone ストア アプリはサポートしています。Note  Windows 10 supports much more of the .NET Framework than a Windows Phone Store app does. たとえば、Windows 10 では、いくつかの System.ServiceModel があります。*名前空間と、System.Net、System.Net.NetworkInformation、および System.Net.Sockets です。For example, Windows 10 has several System.ServiceModel.* namespaces as well as System.Net, System.Net.NetworkInformation, and System.Net.Sockets. そのため、.NET コードをコンパイルして、新しいプラットフォームで動作だけであり、Windows Phone Silverlight に移植する絶好はようになりました。So, now is a great time to port your Windows Phone Silverlight and have your .NET code just compile and work on the new platform. 名前空間とクラス マッピング」をご覧ください。See Namespace and class mappings. Windows 10 アプリに既存の .NET ソース コードを再コンパイルするもう 1 つ優れている理由は、.NET ネイティブ コードから利点が得られますことを MSIL をネイティブ実行可能なマシン語コードに変換する先行コンパイル テクノロジです。Another great reason to recompile your existing .NET source code into a Windows 10 app is that you will benefit from .NET Native, which an ahead-of-time compilation technology that converts MSIL into natively-runnable machine code. .NET ネイティブ アプリは、MSIL アプリに比べて、すばやく起動し、メモリ使用量やバッテリ使用量は少なくなります。.NET Native apps start faster, use less memory, and use less battery than their MSIL counterparts.

この移植ガイドでは XAML に重点を置いていますが、JavaScript 用 Windows ライブラリと共に、JavaScript、カスケード スタイル シート (CSS)、HTML5 を使って、同じ UWP API の多くを呼び出す機能的に同等のアプリを構築できます。This porting guide will focus on XAML but, alternatively, you can build a functionally equivalent app—calling many of the same UWP APIs—using JavaScript, Cascading Style Sheets (CSS), and HTML5 along with the Windows Library for JavaScript. XAML と HTML の Windows ランタイム UI フレームワークは相互に異なりますが、いずれを選んでも一連のさまざまな Windows デバイスで汎用的に動作します。Although the Windows Runtime UI frameworks of XAML and HTML are different from one another, whichever one you choose will work universally across the full range of Windows devices.

ターゲットとしてのユニバーサル デバイス ファミリまたはモバイル デバイス ファミリの設定Targeting the universal or the mobile device family

選択肢の 1 つは、ユニバーサル デバイス ファミリをターゲットとするアプリにアプリを移植することです。One option you have is to port your app to an app that targets the universal device family. この場合、アプリは多様なデバイスにインストールできます。In this case, the app can be installed onto the widest range of devices. アプリがモバイル デバイス ファミリにのみ実装されている API を呼び出す場合は、これらの呼び出しをアダプティブ コードで保護できます。If your app calls APIs that are implemented only in the mobile device family, then you can guard those calls with adaptive code. また、モバイル デバイス ファミリをターゲットとするアプリにアプリを移植することができ、この場合、アダプティブ コードを記述する必要はありません。Alternatively, you can choose to port your app to an app that targets the mobile device family in which case you don't need to write adaptive code.

複数のフォーム ファクターへのアプリの対応Adapting your app to multiple form factors

前のセクションで選択した選択肢によって、アプリが実行されるデバイスの種類が決まります。これは、非常に多種多様なデバイスである場合もあります。The option you choose from the previous section will determine the range of devices that your app or apps will run on, and that may well be a very wide range of devices. アプリをモバイル デバイス ファミリに制限した場合でも、さまざまな画面サイズをサポートする必要があります。Even limiting your app to the mobile device family still leaves you with a wide range of screen sizes to support. 以前はサポートしていなかったフォーム ファクターでアプリが実行されるため、これらのフォーム ファクターで UI をテストし、必要なすべての変更を加えて、UI が各フォーム ファクターに適切に対応するようにします。So, since your app will be running on form factors that it didn't formerly support, test your UI on those form factors and make any change necessary so that your UI adapts appropriately on each. これは、移植後のタスクまたは移植の拡張目標と考えることができます。これについての実践的な例が「Bookstore2」のケース スタディに紹介されています。You can think of this is a post-porting task, or a porting stretch-goal, and there is an example of it in practice in the Bookstore2 case study.

レイヤーごとの移植アプローチApproaching porting layer-by-layer

  • ビューView. ビューは (ビュー モデルと共に)、アプリの UI を構成します。The view (together with the view model) makes up your app's UI. 理想的にはビューは、ビュー モデルの監視可能なプロパティに対するマークアップ バインドから成ります。Ideally, the view consists of markup bound to observable properties of a view model. 直接 UI 要素を操作するためにコード ビハインド ファイル内のコード用に別のパターンが不可欠です (一般的でありまた便利ですが、短期間に限定されます)。Another pattern (common and convenient, but only in the short term) is for imperative code in a code-behind file to directly manipulate UI elements. いずれのケースでも、UI マークアップと設計の多く、そして UI 要素を操作するために不可欠なコードについても、簡単に移植できます。In either case, much of your UI markup and design—and even imperative code that manipulates UI elements—will be straightforward to port.
  • ビュー モデルとデータ モデルView models and data models. 形式的な懸念事項分離パターン (MVVM など) を取り入れていなくても、ビュー モデルおよびデータ モデルの関数を実行するコードがアプリ内に必然的に存在します。Even if you don't formally embrace separation-of-concerns patterns (such as MVVM), there is inevitably code present in your app that performs the function of view model and data model. ビュー モデル コードでは、UI フレームワークの名前空間内の型を使います。View model code makes use of types in the UI framework namespaces. また、ビュー モデルおよびデータ モデル コードは共に、非視覚的なオペレーティング システム API および .NET API を使います (データ アクセス用の API を含みます)。Both view model and data model code also use non-visual operating system and .NET APIs (including APIs for data-access). このようなコードの大半が UWP アプリで利用可能であり、したがって変更なくコードの大半を移植できると考えられます。And the vast majority of those are available to a UWP app, so you can expect to be able to port much of this code without change. ただし、ビュー モデルは、ビューのモデルまたはアブストラクションであることに注意してください。Remember, though: a view model is a model, or abstraction, of a view. ビュー モデルは UI の状態と動作を提供するのに対して、ビューそれ自体は視覚効果を提供します。A view model provides the state and behavior of UI, while the view itself provides the visuals. このような理由から、UWP で実行可能な異なるフォーム ファクターに適合するどのような UI でも、おそらく対応するビュー モデルの変更が必要になります。For this reason, any UI you adapt to the different form factors that the UWP allows you to run on will likely need corresponding view model changes. ネットワークとクラウド サービスの呼び出しについては、通常、.NET API と UWP API のいずれを使うかを選択できます。For networking and calling cloud services, you typically have the option between using .NET or UWP APIs. この決定に関連する要因については、「クラウド サービス、ネットワーク、データベース」をご覧ください。For the factors involved in making that decision, see Cloud services, networking, and databases.
  • クラウド サービスCloud services. アプリのいくつか (おそらく、その多く) が、サービスの形式でクラウド内で実行されます。It's likely that some of your app (perhaps a great deal of it) runs in the cloud in the form of services. クライアント デバイス上で実行する一部のアプリは、こうしたアプリに接続します。The part of the app running on the client device connects to those. これは、クライアント部分の移植時に、変化しない可能性が最も高い分散アプリの部分です。This is the part of a distributed app most likely to remain unchanged when porting the client part. クラウド サービスをまだ利用していない場合は、UWP アプリに適したクラウド サービス オプションとして Microsoft Azure Mobile Services があります。これは、ライブ タイル更新のための簡単な通知から、サーバー ファームが提供する高負荷のスケーラビリティに至るまで、さまざまなサービスのためにユニバーサル Windows アプリから呼び出すことができる強力なバックエンド コンポーネントを提供します。If you don't already have one, a good cloud services option for your UWP app is Microsoft Azure Mobile Services, which provides powerful back-end components that Universal Windows apps can call for services ranging from simple notifications for live tiles updates up to the kind of heavy-lifting scalability a server farm can provide.

移植前または移植中に、同様の目的を持つコードがレイヤー内に集められ、随意に散在しないように、アプリがリファクタリングによって向上するかどうかを考慮します。Before or during the porting, consider whether your app could be improved by refactoring it so that code with a similar purpose is gathered together in layers and not scattered arbitrarily. 前述したように、UWP アプリをレイヤーにファクタリングすることで、アプリの適合性、テスト、以降の読み取りと維持が容易になります。Factoring your UWP app into layers like those described above makes it easier for you to make your app correct, to test it, and then subsequently to read and maintain it. Model-View-ViewModel (MVVM) パターンに従うことにより、機能の再利用性を高め、プラットフォーム間の UI API の相違によるいくつかの問題を回避できます。You can make functionality more reusable—and avoid some issues of UI API differences between platforms—by following the Model-View-ViewModel (MVVM) pattern. このパターンにより、アプリのデータ部、ビジネス部、UI 部の相互の分離性が維持されます。This pattern keeps the data, business, and UI parts of your app separate from one another. UI 内であっても、状態と動作を別個に維持し、視覚効果から個別にテスト可能にすることができます。Even within the UI it can keep state and behavior separate, and separately testable, from the visuals. MVVM により、データおよびビジネス ロジックを 1 回記述すれば、UI に関係なく、それをすべてのデバイスで使うことができます。With MVVM, you can write your data and business logic once and use it on all devices no matter the UI. 各デバイスで、ビュー モデルとビュー部品の多くを再利用できる可能性があります。It's likely that you'll be able to re-use much of the view model and view parts across devices, too.

いくつかの例外One or two exceptions to the rule

この移植ガイドでは、「名前空間とクラス マッピング」も随時ご覧ください。As you read this porting guide, you can refer to Namespace and class mappings. 非常に簡単なマッピングが一般的な規則ですが、名前空間とクラス マッピング表にすべての例外が示されています。Fairly straightforward mapping is the general rule, and the namespace and class mappings table describes any exceptions.

機能レベルでは、さいわいなことに、UWP でサポートされないものは非常にわずかです。At the feature level, the good news is that there's very little that's not supported in the UWP. この移植ガイドの以降の部分では、自身のスキル セットとソース コードの大半を UWP アプリで有効に活用できます。Most of your skill set and source code translates very well over to UWP apps, as you'll read in the rest of this porting guide. しかし、ここではいくつかの Windows Phone Silverlight 機能可能性がありますを使用しているの UWP 相当するものはありません。But, here are the few Windows Phone Silverlight features that you may have used for which there is no UWP equivalent.

UWP に相当要素がない機能Feature for which there is no UWP equivalent Windows Phone の Silverlight 機能のドキュメントWindows Phone Silverlight documentation for the feature
Microsoft XNA。Microsoft XNA. 一般に、C++ を使った Microsoft DirectX に置き換えられます。In general, Microsoft DirectX using C++ is the replacement. ゲームの開発」と「DirectX と XAML の相互運用機能」をご覧ください。See Developing games and DirectX and XAML interop. XNA Framework クラス ライブラリXNA Framework Class Library
レンズ アプリLens apps Windows Phone 8 のレンズLenses for Windows Phone 8

 

トピックTopic 説明Description
Namespace およびクラスのマッピングNamespace and class mappings このトピックでは、同等の UWP に Windows Phone Silverlight Api の包括的なマッピングを提供します。This topic provides a comprehensive mapping of Windows Phone Silverlight APIs to their UWP equivalents.
プロジェクトの移植Porting the project 移植プロセスを始めるには、Visual Studio で新しい Windows 10 プロジェクトを作成し、ファイルをコピーします。You begin the porting process by creating a new Windows 10 project in Visual Studio and copying your files into it.
トラブルシューティングTroubleshooting この移植ガイドは最後まで読むことを強くお勧めしますが、早く先へ進んで、プロジェクトのビルドと実行の段階まで到達したいと思われるのも無理のないことです。We highly recommend reading to the end of this porting guide, but we also understand that you're eager to forge ahead and get to the stage where your project builds and runs. このために、重要でないコードに対してコメント アウトやスタブの挿入を行って一時的に先に進み、後でその部分に戻って対応することもできます。To that end, you can make temporary progress by commenting or stubbing out any non-essential code, and then returning to pay off that debt later. このトピックには、トラブルシューティングの現象とその対処法を示す表が記載されており、以降のいくつかのトピックに示されている情報に代わるものではありませんが、この段階での作業に役立ちます。The table of troubleshooting symptoms and remedies in this topic may be helpful to you at this stage, although it's not a substitute for reading the next few topics. 以降のトピックを読み進む中で、いつでもこの表に戻って参考にすることができます。You can always refer back to the table as you progress through the later topics.
XAML と UI の移植Porting XAML and UI UWP アプリを Windows Phone Silverlight から非常に優れた UI を定義する宣言型の XAML マークアップの形式での実践に変換します。The practice of defining UI in the form of declarative XAML markup translates extremely well from Windows Phone Silverlight to UWP apps. システムのリソース キーの参照の更新、いくつかの要素型名の変更、"clr-namespace" から "using" への変更を行うことによって、大きなマークアップ セクションで互換性が得られることがわかります。You'll find that large sections of your markup are compatible once you've updated system Resource key references, changed some element type names, and changed "clr-namespace" to "using".
I/O、デバイス、およびアプリのモデルの移植Porting for I/O, device, and app model デバイス自体とそのセンサーに統合するコードには、ユーザーに対する入力と出力が含まれます。Code that integrates with the device itself and its sensors involves input from, and output to, the user. また、データ処理を含むこともあります。It can also involve processing data. ただしこのコードは一般には、UI レイヤーまたはデータ レイヤーのいずれにも見なされません。But, this code is not generally thought of as either the UI layer or the data layer. このコードには、振動コントローラー、加速度計、ジャイロスコープ、マイクとスピーカー (音声認識と音声合成で使います)、地理位置情報、およびタッチ、マウス、キーボード、ペンなどの入力モダリティとの統合が含まれます。This code includes integration with the vibration controller, accelerometer, gyroscope, microphone and speaker (which intersect with speech recognition and synthesis), (geo)location, and input modalities such as touch, mouse, keyboard, and pen.
ビジネス データおよびデータ層の移植Porting business and data layers UI の背後には、ビジネス レイヤーとデータ レイヤーがあります。Behind your UI are your business and data layers. こうしたレイヤーのコードでは、オペレーティング システムと .NET Framework API (たとえば、バックグラウンド処理、場所、カメラ、ファイル システム、ネットワーク、その他のデータ アクセスなど) を呼び出します。The code in these layers calls operating system and .NET Framework APIs (for example, background processing, location, the camera, the file system, network, and other data access). このようなコードの大半が UWP アプリで利用可能であり、したがって変更なくコードの大半を移植できると考えられます。The vast majority of those are available to a UWP app, so you can expect to be able to port much of this code without change.
フォーム ファクターと UX の移植Porting for form factor and UX Windows アプリは、PC、モバイル デバイス、その他の多くの種類のデバイスで同じ外観を共有します。Windows apps share a common look-and-feel across PCs, mobile devices, and many other kinds of devices. ユーザー インターフェイス、入力パターン、操作パターンは非常に類似しており、デバイス間を移行するユーザーには使い慣れたエクスペリエンスは歓迎されるはずです。The user interface, input, and interaction patterns are very similar, and a user moving between devices will welcome the familiar experience.
ケース スタディ:Bookstore1Case study: Bookstore1 このトピックでは、Windows 10 UWP アプリへの非常に単純な Windows Phone Silverlight アプリの移植のケース スタディを表示します。This topic presents a case study of porting a very simple Windows Phone Silverlight app to a Windows 10 UWP app. Windows 10 ではパッケージを作成する 1 つのアプリをさまざまなデバイス、上に顧客をインストールし、このケース スタディでは何です。With Windows 10, you can create a single app package that your customers can install onto a wide range of devices, and that's what we'll do in this case study.
ケース スタディ:Bookstore2Case study: Bookstore2 このケース スタディ: 提供された情報に基づくBookstore1: グループ化されたデータを表示するアプリを Windows Phone Silverlight で始まる、 LongListSelectorします。This case study—which builds on the info given in Bookstore1—begins with a Windows Phone Silverlight app that displays grouped data in a LongListSelector. ビュー モデルでは、Author クラスの各インスタンスは、該当する著者によって書かれた書籍のグループを表します。LongListSelector では、著者ごとにグループ化された書籍の一覧を表示したり、縮小して著者のジャンプ リストを表示したりすることができます。In the view model, each instance of the class Author represents the group of the books written by that author, and in the LongListSelector, we can either view the list of books grouped by author or we can zoom out to see a jump list of authors.

ドキュメントDocumentation

MSDN マガジンの記事Magazine articles

プレゼンテーションPresentations