Visual C++ のメジャー バージョン 14 は、Visual Studio 2015 と Visual Studio 2017 に採用されているものになります。Visual Studio 2017 の VC++ では、言語機能の拡張なども行われていますのでマイナー バージョンなどは Visual Studio 2015 と異なることになります。ここに記載している以外の Visual C++ や他のコンパイラの場合は、C ランタイムをスタティック リンクしている場合が、デスクトップ ブリッジで動かすのに簡単な方法になります。スタティック リンクできていない場合は、実行ファイルと同じ場所にランタイム DLL などを配置して、ランタイムをロードできるようにする方法などでもデスクトップ ブリッジで使えるようになります。

VC14 以降とそれ以前は、VC ランタイムの扱いが大幅に変更されています。それは、VC14 以降で VC ランタイムが再設計されていまして、Windows 10 に含まれるようになったことから、ユニバーサル C ランタイム(UCRT)と呼ばれおり、VC ランタイム自体のスタティック リンクができなくなったことです。このため、Windows 7 や Windows 8.1 にバイナリを配布する場合は、VC ランタイムの再配布モジュールをインストールする必要があります。配布対象の Windows 10 に VC14のランタイムが含まれていない場合は、Windows Update 経由で導入するか、再配布モジュールでインストールします。
※VC14でスタティック リンクできないのは、VC ランタイムだけである点にご注意ください。自分で開発したライブラリについては、スタティック リンクすることができます。

前述の表に記述した VCバージョンは、デスクトップ ブリッジで使用する場合にダイナミック リンクで使用するのが簡単になります。ダイナミック リンクを使用する場合は、備考欄のダウンロード リンクより、デスクトップ ブリッジ用のランタイムをダウンロードしておく必要があります。
Visual Studio 2017 の場合は、「%ProgramFiles(x86)\Microsoft SDKs\Windows Kits\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0\Appx」フォルダにランタイムの Appx パッケージがあります。

これらのランタイム パッケージを使用するには、「Using Visual C++ Runtime in Centennial project」の記事に記載されていますが、AppxManifest.xml の 「Dependencies」要素に次のように記載します。
VC11 の場合

<PackageDependency Name=”Microsoft.VCLibs.110.00.UWPDesktop” MinVersion=”11.0.61135.0″ Publisher=”CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US” />

<PackageDependency Name=”Microsoft.VCLibs.120.00.UWPDesktop” MinVersion=”12.0.40653.0″ Publisher=”CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US” />

<PackageDependency Name=”Microsoft.VCLibs.140.00.UWPDesktop” MinVersion=”14.0.23810.0″ Publisher=”CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US” />

<PackageDependency Name=”Microsoft.VCLibs.140.00.UWPDesktop” MinVersion=”14.0.25426.0″ Publisher=”CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US” />

記載したバージョン番号は、ダウンロードなどして入手したランタイム内に存在する SDKManifest.xml と Appx 内の AppxManifes.xml で確認したものになります。 デバッグ用のランタイムを指定する場合は、「Name属性」と「MinVersion属性」を変更する必要があります。このランタイムは、最小バージョンが指定されていますので、Visual Studio 2015 で開発したものも、最新の VC14 ランタイムで動作する可能性がありますので、十分な動作確認を行ってください。
逆に、Visual Studio 2017 で開発したバイナリは、Visual Studio 2015 のランタイムしかない場合は動かないとお考えください。これは、ランタイムのバージョン番号は、上位互換が基本となるからです。

VCのランタイムは、開発した Appx パッケージのテスト時は手作業(Add-AppxPackage)でインストールする必要はありますが、ストアで公開できた場合は、アプリのインストール時に自動的にインストールされるものになります。

Desktop App Converter は、バージョン 2.1.1.0がリリースされており、ベースイメージも Fall Caretors Update向けがリリースされていますので、Fall Creators Updateでも問題なくアプリ パッケージの開発を行うことができるようになっています。

最後に、Windows SDK を基準に考えた場合の、VC ランタイムというか、バージョンについて説明します。Windows 10 SDK に対応しているのは、Visual Studio 2015 / 2017 の VC14 になります。一方で、Windows 8.1 SDK には Visual Studio 2012以降のバージョンが対応しています。このことは、Windows 10 SDK を使用する場合は、ユニバーサル C ランタイムを使うということを意味します。つまり、

• Windows 8.1 SDK：このSDKまでは、従来の VC ランタイムをベースにしています。
• Windows 10 SDK：ユニバーサル C ランタイム(UCRT) をベースにしています。

ということを意味します。このことは、Windows 8.1 SDK を使って Windows 10 で追加された API を使用する場合は、LoadLibrary関数を使って工夫する必要があることを意味しています。

このエントリによると、ダウンロード センターより BaseImage-15063-UPDATE.wim をダウンロードして、ベース イメージを入れ替えて下さいとあります。入れ替えるためには、以下の2種類のコマンドを使用します。

• ベース イメージの削除：「DesktopAppConverter –Cleanup ExpandedImage」
• ベース イメージのインストール：「DesktopAppConverter –Setup –BaseImage “フルパス\BaseImage-15063-UPDATE.wim”」

この問題は、Windows 10 ビルド 15063.486 以降では、ベース イメージがビルド 15063.483 以降を要求するためです。 削除する前のベース イメージは 15063.0 になっています。ベース イメージを入れ替えれば、Desktop App Converter による変換は成功しますが、もう 1 つ問題が発生します。それは、Desktop App Converter が出力するフォルダに関するアクセス権限(ACL)によって、「PackageFiles\AppxManifest.xml」を使って「Add-AppxPackage -Register AppxManifest.xml」コマンドでインストールしたアプリを起動しようとすると、「パラメータが間違っています」というエラーが発生することです。これは、アクセス権限の問題ですので、解決方法は次の2種類のどれかになります。

• 出力先のフォルダをカレントにして「icacls * /t /reset」コマンドでアクセス権限をリセットする。
• Windows エクスプローラーを使って、出力先のフォルダのアクセス権限を修正する。

アクセス権限を変更するのは、サインインしたユーザーに対してフル コントロールを与えるということです。Desktop App Converter は管理者権限で実行し、出力先フォルダがカレント ユーザーに対する権限を継承しないために、アクセス権の変更が必要になったということです。もちろん、Appx パッケージを作成してインストールする場合は、この問題の影響はございません。

• コマンド ライン(cmd.exe)
• PowerShell (powershell.exe)
• レジストリ エディタ(regedit.exe)
• etc

• SiPolicy_Audit.p7b 製品モードと同じで、イベント ログの CodeIntegrityに詳細なログを記録します。 追記:動作を制限するのではなく、ログに動作が記録されます。ログを使って、改善の検討をします。
• SiPolicy_Enforced.p7b 製品モードで、Windows ストアから配信されるアプリのみをインストールできます。
• SiPolicy_DevMode_Enforced.p7b 製品モードに加えて、同梱している証明書に対してだけ サイド ローディングを許可します。 AppxTestRootAgency.pfx の発行者は、「CN=Appx Test Root Agency」になっています。

• アイコンの種類が大幅に増えたこと AppLargeTile.scale-xxx.png, AppList..scale-xxx.png, AppMedTile.scale-xxx.png, AppSmallTile.scale-xxx.png, AppWideTile.scale-xxx.png, AppStoreLogo.scale-xxx.png, AppList.targetsize-xxx.png, scale は、100、125、150、200、400 の 5 種類で targetsize は、16、24、32、48、256 で通常と altform-unplated の 2 種類のために 10 種類になっています。エントリー ポイントの実行ファイル (EXE) にアイコン リソースが含まれていると、アイコン リソースから自動生成されます。
• スケーリング対応による AppxManifest.xml への影響 Resource 要素の uap:Scale に 100、125、150、200、400 を定義。 各種のアセット名は、スケーリング対応(ファイル名に scale-xxx や targetsize-xxx を含まない)。 uap:DefaultTile 要素が追加されました。 uap:ShowNameOnTiles 要素が追加されました。
• -MakeAppx オプションを指定した場合に、 PRI を自動生成。 resources.pri、resources.scale-100.pri、 resources.scale-125.pri、resources.scale-150.pri、 resources.scale-200.pri の 5種類が パッケージ ルートに追加されます。 -MakeAppx オプションを指定しない場合でも、スケーリング対応アセットになっているので、Appx の作成時には PRI を作成する必要があります。

-MakeAppx オプションを指定しない場合

• スケーリング対応アセットを使用しない。
• PRI リソースを自分で作成する。

1. PRI 設定ファイルの作成
2. MakePri.exe ユーティリティを使って、PRI ファイルを作成します。
3. パッケージ レイアウトに作成した PRI リソースを配置します。
4. MakeAppx.exe ユーティリティに「/l」(エル)オプションを指定して、Appxを作成します。 /lオプションが無いと、AppxManifest.xml に指定したファイル名が存在しないというエラーになります。

1. ［スタート メニュー]-[Desktop App Converter] を起動します。
2. タスク マネージャーを起動します。
3. タスク マネージャーで「DACTileLauncher.exe」のコンテキスト メニューから[ファイルの場所を開く]をクリックします。
4. 「icon_extract」フォルダを開き、 PriConfig.xml と layout.resfiles を作業用のフォルダにコピーしておきます。 コピーした PriConfig.xml と layout.resfiles は、どこかに原本として保管してください。DAC で変換した場合に、何度も使用するからです。 PriConfig.xml と layout.resfiles の場所は、DesktopAppConverter.ps1 のスクリプトに記述されています。

• C:\DAC  作業用のルート フォルダ
• C:\DAC\VLC  DACに指定したパッケージ名のフォルダで、次のサブ フォルダが作成されています。 PackgeFiles  DAC が出力した Appx レイアウトのフォルダ logs  DAC が出力したログ用のフォルダ

• アイコン アセットのファイル名を変更した時には、Resources.pri を作り直す必要があります。
• Resources.pri を作り直す時は、Appx レイアウト フォルダにコピーした PRI ファイルを削除しておきます。 MakePri.exe ユーティリティの規定の動作が PRI リソースのマージになっているためです。マージ動作では、変更されていないリソースがあると重複のエラーが発生します。

-MakeAppx オプションを指定する場合

Subject: About DAC and PRI Resources

• Auto generate the Icon Assets from Icon resource of executable file. AppLargeTile.scale-xxx.png, AppList..scale-xxx.png, AppMedTile.scale-xxx.png, AppSmallTile.scale-xxx.png, AppWideTile.scale-xxx.png, AppStoreLogo.scale-xxx.png, AppList.targetsize-xxx.png, Kind of scale is 100,  125, 150, 200 and 400. Kind of targetsize is 16, 24, 32, 48, 256. So two type is targetsize-xxx and taregetsize-xxx_altform-unplated.
• Support scaling assets in AppxManifest.xml. Add uap:Scale, 100 and 125 and 150 and 500, in Resources element. Add uap:DefaultTile. Add uap:ShowNameOnTiles element.
• Auto generate PRI resources with -MakeAppx option. Appx package include resources.pri, resources.scale-100.pri, resources.scale-125.pri, resources.scale-150.pri, resources.scale-200.pri. If not use -MakeAppx option, you must create PRI resources. Because the assets became scaling assets.

No -MakeAppx option

• Not use scaling assets.
• You create PRI resources.

1. Create PRI configuration file.
2.  Create PRI resources with MakePri.exe.
3. locate PRI resources in Appx Package layout.
4. Create appx package by using MakeAppx.exe with /l option. If not use /l option, MakeAppx.exe report error as no exist assets file name.

1.  Launch [Desktop App Converter] in Start menu.
2. Launch Task Manager.
3. Select DACTileLauncher.exe on Task Manager, then open context menu and select "Open file location".
4. Open icon_extract folder in Windows Explorer, copy PriConfig.xml and layout.resfiles to your work folder. This two files, when create appx packge, you modify it.

• C:\DAC             :root folder of work folder.
• C:\DAC\VLC   :it's DAC's output folder. PackgeFiles      :Appx layout folder. logs                    :DAC's log files folder.

• When change assets file name, you must re-create PRI resources.
• When re-create PRI resources, you must delete exist PRI files. Because MakePri default  is merge mode. The merge mode report error as duplicate resources.

• C:\Work\BAT フォルダ ： 変換の作業フォルダー
• C:\Work\BAT\Input フォルダ ： インストーラなどを配置するフォルダ
  MyApp.exe ： 実行ファイル
  Install.bat : インストール用のバッチ ファイル

Install.bat には、次のような内容を記述しています。

mkdir "%ProgramFiles%\MyApp"
xcopy ".\*" "%ProgramFiles%\MyApp" /S /E
exit 0

xcopy コマンドのソースに「.\*」のように、カレントからの相対パスを記述しているのが重要な点になります。

この準備ができたら、DAC を管理者権限で起動して、次のように入力します。

cd C:\Work\BAT
DesktopAppConverter.exe -Installer ".\Input\Install.bat" -Destination "."
  -AppInstallPath "C:\Program Files\MyApp" 
  -AppExecutable "C:\Program Files\MyApp\MyApp.exe"
  -PackageName "myapp" -Publisher "CN=myapp" -Version "0.0.0.1" -Vervos

パラメータが長いので折り返していますが、カレントを変更して、DACのコマンドをワン ライナーで入力します。このコマンドでの特徴は次のようになります。

• -Installer に バッチ ファイルを指定しています。
• -InstallerArguments は省略しています。この理由は、バッチ ファイルで引数を処理していないからです。
• -InstallerValidExitCodes は省略しています。この理由は、バッチ ファイルの最後で「exit 0」としてリターン コードを0(ゼロ)にしているからです。
• -AppInstallPath は、アプリケーションのインストール先のフォルダをフルパスで指定します。
• -AppExecutable は、アプリケーションの実行ファイルをフルパスで 指定します。

こうすることで、正常に変換を行うことができるようになります。

この時の注意事項は、インストール用のバッチ ファイルの xcopy コマンドのソース パスの記述方法になります。最初は、「.\Input\*」のように記述していました。この記述で実行すると、うまく実行はできるのですが、実行結果として「MyApp.exe が見つかりません」という警告が表示されて、出力先の「myapp\PackageFile フォルダ」内に、MyApp.exe が出力されていませんでした。この原因を調べていくと、次のようなことが判明しました。

• インストール用のコンテナのインスタンス内の「C:\shared\installer」フォルダ内に、-Installer で指定したファイルがコピーされるということ。
  つまり、この例では「Installer.bat」を配置したフォルダである「C:\Work\BAT\Input」フォルダ内のファイルが再帰的にコピーされる。
• 「C:\shared\installer\Install.bat」 は、「C:\shared\installer」をカレントにして呼び出されるということ。
  つまり、「.\Input」では、パスが間違っていて、ファイルがコピーされないということです。

結論から言えば、インストール用のバッチ ファイルは、バッチ ファイルを配置した場所をカレント フォルダとして呼び出されるので、このことを前提にパスを記述しないといけないということです。このように手順を踏めば、バッチ ファイルを使ってもアプリを変換することが可能になるわけです。

日本語版の互換性ガイドブックは、Technet の Windows 10 法人向け技術情報まとめ ページに掲載してあります。

何年も Windows 8.1 に対応した互換性ガイド ブックが公開されなかった経緯ですが、

• Windows 8 と Windows Server 2012 互換性ガイドブックが、Windows 7 以前からのマイグレーション用に翻訳されて公開されていました。
• Windows 8.1 がリリースされた時に、新しい互換性ガイドブックが翻訳されませんでした。
• 翻訳されなかったため、互換性ガイドブックのダウンロード センターのページでは、英語版を選択すると Windows 8.1 の Cookbook がダウンロードできて、日本語版を選択すると Windows 8 と Windows Server 2012 互換性ガイドブックのダウンロードができました。
• ダウンロード センターのコンテンツの整理作業が行われた時に、日本語版のWindows 8 と Windows Server 2012 互換性ガイドブックのリンクが削除されてしまいました。というのは、ダウンロード センターの整理作業時点で、英語版の Windows 8 向けの Compatibility Cookbook は、Windows 8.1 用に収録されていることから Windows 8 向けは不要という判断になったためです。
• Windows 10 の Compatibility Cookbook が公開されて、日本語版も公開しました。が、Windows 10 の互換性ガイドブックは、Windows 8.1 からの差分として構成されていることから、日本のお客様向けに Windows 8.1 向けの互換性ガイドブックを用意する必要性を私は感じていました。
• このような考えを持っていましたので、色々な方の助けを借りて Windows 8.1 向けの互換性ガイドブックを作成しました。

この機会に、是非、互換性ガイドブックのダウンロードをお願いします。

最初の入門として見るのは、HelloWorldSample か JourneyAcrossTheBridge のサンプルになります。

HelloWorldSample

cs フォルダと CentennialPackage フォルダが含まれており、cs フォルダが C# のコンソール アプリケーションになっており、CentennialPackage フォルダは、手作業でAppxを作成するための Appx レイアウト フォルダになっています。このサンプルでは、Desktop App Converter を使用することなく、デスクトップ アプリを Appx パッケージにすることを学習するためのものになっています。

JourneyAccrossTheBridge

このサンプルには、ステップ1からステップ5までの5種類が含まれています。学習の流れで説明すると、ステップ1 から ステップ 3が、Windows Forms のデスクトップ アプリを Appx 化 (ステップ1) して、タイル更新を追加(ステップ2)、バックグラウンド タスクを追加(ステップ3) と順番に既存のデスクトップ コードを機能拡張する流れになっています。

ステップ 4 以降は、それまでの流れではなく、UWP のアプリから デスクトップのコードを アプリ サービスとして使用し(ステップ4)、完全な UWP アプリへの移行(ステップ 5)となっています。

ステップ1

学習することは、HelloWorldSample と同じです。異なるのは、コンソール アプリではなく、Windows Forms を使用した GUI のアプリという点であり、使用する Visual Studio が 2015 ではなく、2017(プレビュー)になっており、Desktop to UWP packaging Project を使用するようになっていることです。Desktop to UWP Project で作成したプロジェクトは、Appxレイアウトのフォルダを指定し、変換対象のプロジェクトをソリューションに追加することで、Appx の更新やデバッグが容易になるという特徴があります。Desktop to UWP Project の使い方は、変換済みの UWP アプリを展開してデバッグするに記述されている「F5デバッグ」で詳しく説明しています。

ステップ2

タイル更新を追加するために、Windows.wnimd への参照を追加してから、コンボボックスのSelectionChanged イベント ハンドラ内に TileUpdateManager クラスと TileNotification クラスを使用してタイル通知を行うコードを追加しています。

ステップ3

ステップ2 へバックグラウンド タスクを追加するために、BackgroundTasks プロジェクトを Windows ランタイム コンポーネント プロジェクトとして追加しています。このバックグラウンド タスクは、アプリケーション設定の「Status」キーに設定された文字列を使って、トースト通知を行います。

AppxManifest へバックグラウンド タスクを追加するには、以下の3種類の作業が必要になります。

• Extension 要素で UWP アプリと同様に windows.backgroundTasks の設定を行います。
• Extension 要素で windows.activatableClass.inProcessServer の設定を行います。
  この理由は、デスクトップのアプリなので、アプリの仕組みを自動的に使えないためです。
• 作成した BackgroundTasks.winmd と BackgroundTasks.pri を Appx レイアウトへコピーしておきます。

Windows Forms のアプリケーションでは、以下の作業を行っています。

• Program.cs で、バックグラウンド タスクの登録を行います。コードは、UWP アプリで使用するものと同じです。
• Form1.cs で、Form1_Load イベント ハンドラでアプリケーション設定の [Status] キーへ文字列を設定します。

こうすることで、バックグラウンド タスクが Time トリガーによって 15 分間隔でトースト通知を表示するようになります。

ステップ4

既に説明したように、ここでステップ 3までとは異なる構造へと変わります。具体的には、MyDesktopApp プロジェクト (デスクトップ のアプリ)、BackgroundTasks プロジェクト (これは、ステップ3のものと同じです)、最後に MyUWPApp プロジェクト(純粋な UWP アプリ)の 3 プロジェクトで構成されていて、ステップ 3まで存在していた Desktop to UWP Project は無くなっています。この理由は、MyUWPApp という UWP アプリで配置などを行うからです。

MyDesktopApp プロジェクトの特徴は、次のようになります。

• C# のコンソール アプリケーションです。
• Windows.winmd への参照設定を行っています。
• レジストリに設定している CurrentState を アプリケーション設定の [Status] キーへ保存します。
• 新しいスレッドで AppService をホストするコードを記述しています。AppService で CurrentState を ValueSet をクライアントへ返します。

MyUwpApp プロジェクトの特徴は、次のようになります。

• ターゲット プラットフォームを 10.0.14393.0 に固定します。
• BackgroundTasks プロジェクトへ参照を設定します。
• Windows Desktop Extension 10.0.14393 拡張SDK への参照を設定します。
• ポスト ビルドで、MyDesktopApp の出力である exe と pdb を$(OutDir)AppX フォルダーへコピーします。
• App.xaml.cs の OnBackgroundActivated イベント ハンドラで、AppService の処理を記述し、メッセージを受信したら StatusUpdated イベントを呼び出します。
• MainPage.xaml.cs で、StatusUpdate イベントのハンドラを記述し、受信したメッセージでコンボボックスを選択するコードを記述しています。
  OnNavigatedTo イベント ハンドラで、バックグラウンド タスクの登録をし、FullTrustProcessLauncher クラスを使って MyDesktopApp を起動します。
  コンボボックスの SelectionChanged イベント ハンドラで、MyDesktopApp のApp Service へメッセージを送信し、受信したデータでタイル更新をします。
• Package.appxmanifestには、次のような変更を加えています。
  デバイス ファミリ を Windows.Desktop に固定。
  ネームスペースに、rescap と desktop を追加。
  Extension にバックグラウンド タスクと windows.appServiceの定義を追加し、desktop:Extension 要素で windows.fullTrsustProcess として MyDesktopApp.exe を追加し、rescap:Capability runFullTrust を追加します。

このような構造になっています。ここでポイントは、デスクトップ アプリが AppService をホストしている点と UWP アプリが デスクトップ アプリの AppService を起動するために、FullTrustProcessLauncher クラスを使用している点です。通常の UWP アプリ同士であれば、AppService 側は自動的に起動されますが、デスクトップ アプリでAppService をホストするケースでは、自動的に起動できないので、UWP アプリ 側で起動する必要があるということになります。このための設定が、desktop:Extension の windows.FullTrustProcessになり、この記述は Appx内に同梱した完全信頼の実行ファイルを 1 つだけ記述することができます。

ステップ5

ステップ 4までのソリューションを完全な UWP アプリ化するために、MyUWPAppプロジェクトとBackgroundTasks プロジェクトの ２つだけに統合します。

BackgroundTasksSample

JourneyAccrossTheBridge のステップ 3 と同じになります。

AppServiceBridgeSample

C# と C++ を使用したサンプルがありますが、考え方は JourneyAccrossTheBridge のステップ 4 と同じになります。

NorthwindSample

C# のサンプルで AppService を使用しますので、JourneyAccrossTheBridge のステップ 3と同様の考え方でなりたっていますが、Northwindという名前から予測できるように SQL Compact を使ったデータベースへのアクセスをラップした C# のデスクトップ アプリを使用しています。

StoreSample

ストアのAPIを使用する C# のWPF アプリケーションで、Desktop to UWP packaging Project を使用しています。

このサンプルを通して DAC で変換したアプリを拡張する時に注意点は、以下のようなことになります。

• Windows メタデータへの参照設定が必要
  C++ の場合は、Windows ランタイムを使用できる Windows SDK を使用する必要がある
• UWP アプリから、Appx 内のデスクトップ実行ファイルを起動するには、FullTrustProcessLauncher クラスを使用する。
  同梱できるデスクトップ実行ファイルは 1つだけという制限がある。
• 拡張するには、AppService などがやりやすい。
• タイルやトースト通知を使用する場合は、AppUserModelId が必須(UWP アプリは自動的に付与されます)。

DAC で変換したAppxの価値を高めるためにも、利用シーンに応じた拡張を考えることが重要になってくることでしょう。

• スケール ベース xxxxxx.scale-100.png など、スケーリングの倍率(100、200、400、etc)に応じて切り替えるアセット。
• ターゲットベース xxxxxx.targetseize-16.png など、ターゲット サイズに応じて切り替えるアセット(正方形)で、エクスプローラなどの Windows のシステム側で使用するものになります。

• LockScreenLogo.scale-200.png
• SplashScreen.scale-200.png
• Square44x44Logo.scale-200.png
• Squrae44x44Logo.targetsize-24_altform.png
• Square150x150Logo.scale-200.png
• StoreLogo.png
• Wide310x150Logo.scale-200.png

• SampleAppx.44x44.png (44px x 44px)
• SampleAppx.50x50.png (50px x 50px)
• SampleAppx.150x150.png (300px x 300px)

• SampleAppx150x150.scale-100.png
• SampleAppx150x150.scale-200.png

<?xml version="1.0" encoding="utf-8"?>
<resources targetOsVersion="10.0.0" majorVersion="1">
  <index root="\" startIndexAt="assetslayout.resfiles">
    <default>
      <qualifier name="Language" value="ja-JP" />
      <qualifier name="Contrast" value="standard" />
      <qualifier name="Scale" value="200" />
      <qualifier name="HomeRegion" value="001" />
      <qualifier name="TargetSize" value="256" />
      <qualifier name="LayoutDirection" value="LTR" />
      <qualifier name="DXFeatureLevel" value="DX9" />
      <qualifier name="Configuration" value="" />
      <qualifier name="AlternateForm" value="" />
      <qualifier name="Platform" value="UAP" />
    </default>
    <indexer-config type="RESFILES" qualifierDelimiter="." />
  </index>
</resources>

assets\SampleAppx.44x44.png
assets\SampleAppx.50x50.png
assets\SampleAppx150x150.scale-100.png
assets\SampleAppx150x150.scale-200.png

• 「makepri.exe  new /pr Appxレイアウトのフォルダ /cf priconfig.xml」

• 「makeappx.exe /d Appxレイアウトのフォルダ /l /p appx名.appx」

• 「ApplicationDescription」 キーに値を設定します

• 先に示した index 要素のコピーを作成します。
• 「layout.resfiles」 を 「resources.resfiles」に変更します
• Type="RESFILES"の行に次の二行を追加します。
• <indexer-config Type="RESW" convertDotsSlashes="true" />
• <indexer-config Type="RESJSON" />