レガシ アプリやゲームで Windows 10 のリソース管理システムを使用する
.NET と Win32 のアプリとゲームは、アドレス指定可能な市場全体を拡大するために、多くの場合、異なる言語にローカライズされます。 アプリのローカライズの価値提案の詳細については、「グローバリゼーションとローカライズ」 を参照してください。 .NET または Win32 アプリやゲームを .msix または .appx パッケージとしてパッケージ化することにより、リソース管理システムを活用して実行時のコンテキストに合わせたアプリ リソースを読み込むことができます。 この詳細なトピックでは、この手法について説明します。
従来の Win32 アプリケーションをローカライズする方法は多数ありますが、Windows 8 では、アプリケーションの種類をまたいでプログラミング言語間で動作し、単純なローカライズ以上の機能を提供する新しいリソース管理システムが導入されました。 このシステムは、このトピックでは "MRT" と呼ばれます。 歴史的には、それは「現代のリソース技術」のために立っていましたが、「モダン」という用語は廃止されました。 リソース マネージャーは、MRM (Modern Resource Manager) または PRI (パッケージ リソース インデックス) とも呼ばれます。
MSIX ベースまたは .appx ベースの展開 (Microsoft Store を使った展開など) と組み合わせることにより、MRT はユーザーとデバイスに最適なリソースを自動的に配布します。これにより、アプリケーションのダウンロードとインストールのサイズを最小化することができます。 このサイズの削減は、ローカライズされたコンテンツが大量に含まれるアプリケーションでは、おそらく AAA ゲームでは数 ギガバイト 単位で大きくなる可能性があります。 MRT のその他の利点としては、Windows シェルと Microsoft Store のローカライズされた登録情報、ユーザーの優先言語が使用可能なリソースと一致しない場合の自動フォールバック ロジックなどがあります。
このドキュメントでは、MRT のアーキテクチャの概要について説明し、従来の Win32 アプリケーションを最小限のコード変更で MRT に移行するための移植ガイドを提供します。 MRT への移行が完了すると、追加の利点 (スケール ファクターやシステム テーマでリソースをセグメント化する機能など) が開発者に提供されるようになります。 MRT ベースのローカライズは、デスクトップ ブリッジによって処理される UWP アプリケーションと Win32 アプリケーションの両方に対して機能します ("Centennial" とも呼ばれる)。
多くの状況では、実行時にリソースを解決し、ダウンロード サイズを最小限に抑えるために MRT と統合しながら、既存のローカライズ形式とソース コードを引き続き使用できます。これは、すべてまたはまったくないアプローチではありません。 次の表は、各ステージの作業と推定コスト/利益をまとめたものです。 この表には、高解像度またはハイ コントラストのアプリケーション アイコンの提供など、ローカライズ以外のタスクは含まれません。 タイル、アイコンなどに複数のアセットを提供する方法の詳細については、「言語、スケール、ハイ コントラスト、その他の修飾子に合わせてリソースを調整する」を参照してください。
| 作業 | 特長 | 推定コスト |
|---|---|---|
| パッケージ マニフェストをローカライズする | ローカライズされたコンテンツを Windows シェルと Microsoft Store に表示するために必要な最小限の作業 | Small |
| MRT を使用してリソースを識別および検索する | ダウンロードとインストールのサイズを最小限に抑えるための前提条件。自動言語フォールバック | 中 |
| リソース パックをビルドする | ダウンロードとインストールのサイズを最小限に抑える最後の手順 | Small |
| MRT リソース形式と API への移行 | ファイル サイズが大幅に小さい (既存のリソース テクノロジに応じて) | Large |
はじめに
ほとんどの単純でないアプリケーションには、アプリケーションのコードから切り離されたリソースと呼ばれるユーザー インターフェイス要素が含まれています (ソース コード自体で作成されるハードコーディングされた値とは対照的)。 ハードコーディングされた値よりもリソースを優先する理由はいくつかあります。たとえば、開発者以外による編集が容易ですが、主な理由の 1 つは、アプリケーションが実行時に同じ論理リソースの異なる表現を選択できるようにすることです。 たとえば、ボタンに表示するテキスト (またはアイコンに表示する画像) は、ユーザーが理解している言語、表示デバイスの特性、またはユーザーが支援技術を有効にしているかどうかによって異なる場合があります。
したがって、リソース管理テクノロジの主な目的は、実行時に、論理またはシンボリックなリソース名 (SAVE_BUTTON_LABELなど) の要求を、一連の候補 (たとえば、「Save」、「Speichern」、「保存」) の中から、実際に最適な値 (たとえば「保存」) に変換することです。 MRT にはこのような機能が用意されており、アプリケーションでは、ユーザーの言語、表示スケール ファクター、ユーザーの選択したテーマ、その他の環境要因など、修飾子と呼ばれるさまざまな属性を使用してリソース候補を識別できます。 さらに MRT は、アプリケーションが必要とする、カスタムの修飾子をサポートします (たとえば、アプリケーションが、ゲスト ユーザーとアカウントを使ってログインしたユーザーに対して、別のグラフィック アセットを提供することができますこれを、アプリケーションのあらゆる部分にチェックのロジックを追加することなく、行えます)。 MRT は、文字列リソースとファイル ベースのリソースの両方で動作します。ファイル ベースのリソースは、外部データ (ファイル自体) への参照として実装されます。
例
次に、2 つのボタン (openButton と saveButton) にテキスト ラベルがあり、ロゴ (logoImage) に PNG ファイルを使用するアプリケーションの簡単な例を示します。 テキスト ラベルは英語とドイツ語にローカライズされ、ロゴは通常のデスクトップ ディスプレイ (100% スケール ファクター) と高解像度電話 (300% スケール ファクター) 用に最適化されています。 この図は、モデルの概念的な概要を示しています。実装に正確にマップされるわけではありません。
図では、アプリケーション コードは 3 つの論理リソース名を参照しています。 実行時に、 GetResource 擬似関数は MRT を使用してリソース テーブル (PRI ファイルと呼ばれます) でこれらのリソース名を検索し、アンビエント条件 (ユーザーの言語とディスプレイのスケール ファクター) に基づいて最も適切な候補を見つけます。 ラベルの場合、文字列は直接使用されます。 ロゴ イメージの場合、文字列はファイル名として解釈され、ファイルはディスクから読み取られます。
ユーザーの言語が英語とドイツ語以外の場合、またディスプレイのスケール ファクターが 100% と 300% 以外の場合は、MRT はフォールバック規則のセットに基づいて、最も "近い" 候補を選びます (背景について詳しくは、「リソース管理システム」をご覧ください)。
MRT では、複数の修飾子に合わせて調整されたリソースがサポートされていることに注意してください。たとえば、ロゴイメージにローカライズする必要がある埋め込みテキストが含まれている場合、ロゴには EN/Scale-100、DE/Scale-100、EN/Scale-300、DE/Scale-300 の 4 つの候補があります。
このドキュメントのセクション
以降のセクションでは、MRT をアプリケーションと統合するために必要な高度なタスクについて説明します。
フェーズ 0: アプリケーション パッケージをビルドする
このセクションでは、既存のデスクトップ アプリケーションをアプリケーション パッケージとしてビルドする方法について説明します。 この段階では MRT 機能は使用されません。
フェーズ 1: マニフェストをローカライズする
このセクションでは、従来のリソース形式と API を使用してリソースをパッケージ化および検索しながら、アプリケーションのマニフェストをローカライズする方法 (Windows シェルに正しく表示されるようにする) 方法について説明します。
フェーズ 2: MRT を使用してリソースを識別して見つける
このセクションでは、既存のリソース形式と API を使用してリソースを読み込んで使用しながら、MRT を使用してリソースを検索するようにアプリケーション コード (および場合によってはリソース レイアウト) を変更する方法について説明します。
フェーズ 3: リソース パックをビルドする
このセクションでは、リソースを個別の リソース パックに分割するために必要な最終的な変更について説明し、アプリのダウンロード (およびインストール) サイズを最小限に抑えます。
このドキュメントでは取り上げません
フェーズ 0 から 3 を完了すると、Microsoft Store に提出できる、アプリケーション "バンドル" が作成されます。これにより、ユーザーは不要なリソース (たとえば、使用しない言語) を省略でき、ダウンロードとインストールのサイズを最小化できます。 アプリケーションのサイズと機能をさらに改善するために、最後の 1 つの手順を実行します。
フェーズ 4: MRT リソース形式と API に移行する
このフェーズは、このドキュメントの範囲外です。これには、リソース (特に文字列) を MUI DLL や .NET リソース アセンブリなどのレガシ形式から PRI ファイルに移動する必要があります。 これにより、ダウンロードとインストールのサイズをさらに節約できます。 また、スケール ファクター、アクセシビリティ設定などに基づいて、イメージ ファイルのダウンロードとインストールを最小限に抑えるなどの他の MRT 機能を使用することもできます。
フェーズ 0: アプリケーション パッケージをビルドする
アプリケーションのリソースに変更を加える前に、まず、現在のパッケージ化とインストールのテクノロジを標準の UWP パッケージ化および展開テクノロジに置き換える必要があります。 これを行うには 3 つの方法があります。
- 複雑なインストーラーを備えた大規模なデスクトップ アプリケーションの場合、または多くの OS 拡張ポイントを利用している場合、Desktop App Converter ツールを使用して、既存のアプリ インストーラー (たとえば MSI) から、UWP ファイル レイアウトとマニフェスト情報を生成できます。
- 比較的少ないファイルを扱う小規模なデスクトップ アプリケーションの場合、または拡張フックを使用しないシンプルなインストーラーの場合、手動でファイル レイアウトとマニフェスト情報を作成できます。
- ソースからのリビルドを行って、アプリを "純粋な" UWP アプリケーションに更新する場合は、Visual Studio で新しいプロジェクトを作成し、IDE を利用して多くの作業を行うことができます。
Desktop App Converter を使用する場合、変換プロセスについて詳しくは Desktop App Converter を使用したデスクトップ アプリケーションのパッケージ化に関するページをご覧ください。 デスクトップ コンバーターのサンプルの完全なセットは、デスクトップ ブリッジから UWP へのサンプル GitHub リポジトリにあります。
パッケージを手動で作成する場合は、すべてのアプリケーション ファイル (実行可能ファイルとコンテンツを含む、ソース コードは含まない) とパッケージ マニフェスト ファイル (.appxmanifest) を含む、ディレクトリ構造を作成する必要があります。 例として GitHub サンプルの Hello, World をご覧ください。ただし、デスクトップの実行可能ファイル ContosoDemo.exe を実行する、基本的なパッケージ マニフェスト ファイルは次のとおりです。強調されているテキストを実際の値に置き換えます。
<?xml version="1.0" encoding="utf-8" ?>
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
IgnorableNamespaces="uap mp rescap">
<Identity Name="Contoso.Demo"
Publisher="CN=Contoso.Demo"
Version="1.0.0.0" />
<Properties>
<DisplayName>Contoso App</DisplayName>
<PublisherDisplayName>Contoso, Inc</PublisherDisplayName>
<Logo>Assets\StoreLogo.png</Logo>
</Properties>
<Dependencies>
<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.14393.0"
MaxVersionTested="10.0.14393.0" />
</Dependencies>
<Resources>
<Resource Language="en-US" />
</Resources>
<Applications>
<Application Id="ContosoDemo" Executable="ContosoDemo.exe"
EntryPoint="Windows.FullTrustApplication">
<uap:VisualElements DisplayName="Contoso Demo" BackgroundColor="#777777"
Square150x150Logo="Assets\Square150x150Logo.png"
Square44x44Logo="Assets\Square44x44Logo.png"
Description="Contoso Demo">
</uap:VisualElements>
</Application>
</Applications>
<Capabilities>
<rescap:Capability Name="runFullTrust" />
</Capabilities>
</Package>
パッケージ マニフェスト ファイルとパッケージ レイアウトについて詳しくは、「アプリ パッケージ マニフェスト」をご覧ください。
最後に、Visual Studio を使って新しいプロジェクトを作成し、既存のコード全体を移行するには、"Hello, world" アプリの作成に関するページをご覧ください。 既存のコードを新しいプロジェクトに含めることはできますが、"純粋な" UWP アプリとして実行するためには、相当なコードの変更 (特にユーザー インターフェイス) が必要となる場合があります。 これらの機能は、このドキュメントの範囲外です。
フェーズ 1: マニフェストをローカライズする
手順 1.1: マニフェストの文字列とアセットを更新する
フェーズ 0 でアプリケーションのための、基本的なパッケージ マニフェスト (.appxmanifest) ファイルを (コンバーターに提供された値に基づき、または MSI ファイルから抽出し、またはマニフェストに手動で入力して) 作成しましたが、これにはローカライズされた情報は含まれていません。また、高解像度用のスタート画面のタイルのアセットなど、追加機能のサポートも含まれません。
アプリケーションの名前と説明が正しくローカライズされるためには、リソース ファイルのセットでリソースを定義し、パッケージ マニフェストを更新して、それらを参照する必要があります。
既定のリソース ファイルの作成
最初の手順では、既定の言語 (たとえば、米国英語) で既定のリソース ファイルを作成します。 これは、テキスト エディターを使用して手動で行うか、Visual Studio のリソース デザイナーを使用して行うことができます。
リソースを手動で作成する場合:
resources.reswという名前の XML ファイルを作成し、プロジェクトのStrings\en-usサブフォルダーに配置します。 既定の言語が英語 (米国) 以外の場合には、適切な BCP-47 コードを使用します。- 各 XML ファイルで、次のコンテンツを追加します。強調表示されたテキストは、適切な言語を使用して、アプリに適切なテキストに置き換えてください。
Note
これらの文字列の一部については、長さに制限があります。 詳細については、「VisualElements」を参照してください。
<?xml version="1.0" encoding="utf-8"?>
<root>
<data name="ApplicationDescription">
<value>Contoso Demo app with localized resources (English)</value>
</data>
<data name="ApplicationDisplayName">
<value>Contoso Demo Sample (English)</value>
</data>
<data name="PackageDisplayName">
<value>Contoso Demo Package (English)</value>
</data>
<data name="PublisherDisplayName">
<value>Contoso Samples, USA</value>
</data>
<data name="TileShortName">
<value>Contoso (EN)</value>
</data>
</root>
Visual Studio でデザイナーを使用する場合:
- プロジェクトで
Strings\en-us(または必要に応じてその他の言語の) フォルダーを作成します。プロジェクトのルート フォルダーに、resources.reswの既定の名前を使って、新しい項目を追加します。 リソース ディクショナリではなく、必ずリソース ファイル (.resw) を選択します。リソース ディクショナリは、XAML アプリケーションで使われるファイルです。 - デザイナを使用して、次の文字列を入力します (同じ
Namesを使用しますが、Valuesをアプリケーションに適したテキストに置き換えます)。
Note
Visual Studio デザイナーで開始する場合は、F7 キーを押すと、いつでも XML を直接編集できます。 ただし、最小限の XML ファイルから始めると、 デザイナーは、追加のメタデータが多数不足しているため、ファイル を認識しません。これを修正するには、デザイナーによって生成されたファイルから手動で編集した XML ファイルに定型 XSD 情報をコピーします。
リソースを参照するようにマニフェストを更新する
.resw ファイルで値を定義した後、マニフェストを更新して、文字列リソースを参照します。 ここでも、XML ファイルを直接編集することも、Visual Studio マニフェスト デザイナーに依存することもできます。
XML を直接編集する場合は、AppxManifest.xml ファイルを開き、強調表示された値に次の変更を行います。これは、アプリケーション固有ではなく、このテキストをそのまま使用します。 これらのリソース名をそのまま使用する必要はありません。独自の名前を使用できますが、それは .resw ファイル内の名前と正確に一致する必要があります。 これらの名前は、Names ファイルで作成した .resw と一致し、接頭辞 ms-resource: スキームと Resources/ 名前空間が付いている必要があります。
Note
このスニペットでは、多くのマニフェストの要素が省略されています。何も削除しないでください。
<?xml version="1.0" encoding="utf-8"?>
<Package>
<Properties>
<DisplayName>ms-resource:Resources/PackageDisplayName</DisplayName>
<PublisherDisplayName>ms-resource:Resources/PublisherDisplayName</PublisherDisplayName>
</Properties>
<Applications>
<Application>
<uap:VisualElements DisplayName="ms-resource:Resources/ApplicationDisplayName"
Description="ms-resource:Resources/ApplicationDescription">
<uap:DefaultTile ShortName="ms-resource:Resources/TileShortName">
<uap:ShowNameOnTiles>
<uap:ShowOn Tile="square150x150Logo" />
</uap:ShowNameOnTiles>
</uap:DefaultTile>
</uap:VisualElements>
</Application>
</Applications>
</Package>
Visual Studio のマニフェスト デザイナーを使っている場合は、.appxmanifest ファイルを開き、*[アプリケーション] タブと [パッケージ化] タブ で、強調されている値を変更します。
手順 1.2: PRI ファイルをビルドし、MSIX パッケージを作成して、動作を確認する
これで、.pri ファイルをビルドしてアプリケーションをデプロイし、正しい情報 (既定の言語) が [スタート] メニューに表示されていることを確認できます。
Visual Studio でビルドする場合は、Ctrl+Shift+B を押してプロジェクトをビルドし、プロジェクトを右クリックしてコンテキスト メニューから Deploy を選択します。
手動でビルドを行う場合は、次の手順に従って、MakePRI ツールの構成ファイルを作成し、.pri ファイル自体を生成します (詳しくは、手動によるアプリのパッケージ化に関するページをご覧ください)。
スタート メニューの Visual Studio 2017 または Visual Studio 2019 のフォルダーで、開発者用コマンド プロンプトを開きます。
プロジェクトのルート ディレクトリに切り替えます (.appxmanifest ファイルと [Strings] フォルダーが含まれます)。
次のコマンドを入力し、"contoso_demo.xml" をプロジェクトに適した名前に置き換え、"en-US" をアプリの既定の言語に置き換えます (または、該当する場合は en-US のままにします)。 XML ファイルは (プロジェクト ディレクトリではなく) 親ディレクトリに作成されることに注意してください。これはアプリケーションの一部ではないためです (他の任意のディレクトリを選択できますが、それ以降のコマンドで必ず、名前を変更してください)。
makepri createconfig /cf ..\contoso_demo.xml /dq en-US /pv 10.0 /omakepri createconfig /?と入力すると、各パラメーターの機能を大略確認できます。/cf: 構成ファイル名 (このコマンドの出力) を設定します/dq: 既定の修飾子を設定します。この場合は言語en-USです/pv: プラットフォームのバージョンを設定します。この場合は Windows 10 です/o: 出力ファイルが存在する場合、上書きします
これで構成ファイルができたので、もう一度
MakePRIを実行して、実際にディスクでリソースを検索し、それらを PRI ファイルにパッケージ化します。 "contoso_demop.xml" を前の手順で使用した XML ファイル名に置き換え、入力と出力の両方に親ディレクトリを指定してください。makepri new /pr . /cf ..\contoso_demo.xml /of ..\resources.pri /mf AppX /omakepri new /?と入力すると、各パラメーターの機能を大略確認できます。/pr: プロジェクトのルートを設定します (この場合は、現在のディレクトリです)/cf: 前の手順で作成した、構成ファイル名を設定します/of: 出力ファイルを設定します/mf: マッピング ファイルを作成します (後の手順で、パッケージからファイルを除外できるようにします)/o: 出力ファイルが存在する場合、上書きします
これで、既定の言語リソース (en-US など) を含む
.priファイルが作成されました。 keytab が正しいことを確認するには、次のコマンドを実行します。makepri dump /if ..\resources.pri /of ..\resources /omakepri dump /?と入力すると、各パラメーターの機能を大略確認できます。/if: 入力ファイル名を設定します/of: 出力ファイル名を設定します (.xmlは自動的に追加されます)/o: 出力ファイルが存在する場合、上書きします
最後に、テキストエディタで
..\resources.xmlを開き、選択したデフォルト言語の<NamedResource>の値(ApplicationDescriptionとPublisherDisplayNameなど)と<Candidate>の値がリストされていることを確認できます(ファイルの先頭に他のコンテンツがありますが、ここでは無視してください)。
マッピング ファイル ..\resources.map.txt を開いて、プロジェクトに必要なファイル (PRI ファイルを含みます。これはプロジェクトのディレクトリの一部ではありません) が含まれていることを確認します。 マッピング ファイルには、resources.resw ファイルへの参照は含まれていません。これは重要です。そのファイルの内容は既に PRI ファイルに埋め込まれているためです。 ただし、画像のファイル名などの他のリソースが含まれます。
パッケージをビルドして署名する
PRI ファイルがビルドされたので、パッケージをビルドして署名できます。
アプリ パッケージを作成するには、作成する .msix/.appx ファイルの名前で
contoso_demo.appxを置き換えて、次のコマンドを実行します。ファイルに別のディレクトリを選択するようにします (このサンプルでは親ディレクトリを使用しています。任意のディレクトリを指定できますが、プロジェクト ディレクトリ以外を指定する必要があります)。makeappx pack /m AppXManifest.xml /f ..\resources.map.txt /p ..\contoso_demo.appx /omakeappx pack /?と入力すると、各パラメーターの機能を大略確認できます。/m: 使用するマニフェスト ファイルを設定します/f: (前の手順で作成された) 使用するマッピング ファイルを設定します/p: 出力パッケージの名前を設定します/o: 出力ファイルが存在する場合、上書きします
パッケージが作成されたら、それに署名する必要があります。 署名証明書を取得する最も簡単な方法は、Visual Studio で空のユニバーサル Windows プロジェクトを作成して、作成された
.pfxファイルをコピーすることです。またMakeCertユーティリティとPvk2Pfxユーティリティを使って、手動で作成することもできます。詳しくは、「アプリ パッケージの署名証明書を作成する方法」をご覧ください。重要
署名証明書を手動で作成した場合、必ずソース プロジェクトまたはパッケージ ソースとは別のディレクトリにファイルを配置します。そうしない場合、秘密キーも含めてパッケージに含まれてしまう場合があります。
次のコマンドを使用して、パッケージをビルドします。
AppxManifest.xmlのIdentity要素で指定されているPublisherは、証明書のSubjectと一致する必要があります (これは<PublisherDisplayName>要素ではありません。それはユーザーに表示されるローカライズされた表示名です)。 通常と同様に、contoso_demo...のファイル名をプロジェクトに適した名前で置き換えます。さらに.pfxファイルが現在のディレクトリにないことを確認します (これは非常に重要です。そうしない場合、プライベート署名キーを含めて、パッケージの一部として作成されてしまいます)。signtool sign /fd SHA256 /a /f ..\contoso_demo_key.pfx ..\contoso_demo.appxsigntool sign /?と入力すると、各パラメーターの機能を大略確認できます。/fd: ファイル ダイジェスト アルゴリズムを設定します (.appx の既定は SHA256 です)/a: 最適な証明書を自動的に選択します/f: 署名証明書を含む入力ファイルを指定します
最後に、.appx ファイルをダブルクリックしてインストールするか、コマンド ラインを使用する場合は、PowerShell プロンプトを開き、パッケージを含むディレクトリに移動して、次のように入力します (contoso_demo.appxパッケージ名に置き換えてください)。
add-appxpackage contoso_demo.appx
証明書が信頼されていないというエラーが表示された場合は、証明書が (ユーザー ストアではなく) コンピューター ストアに追加されていることを確認します。 コンピューター ストアに証明書を追加するには、コマンド ラインまたは Windows エクスプローラーを使用します。
コマンド ラインを使用するします。
Visual Studio 2017 または Visual Studio 2019 のコマンド プロンプトを管理者として実行します。
.cerファイルを含むディレクトリに切り替えます (これがソース ディレクトリまたはプロジェクト ディレクトリの外部にあることを確認してください)。次のコマンドを入力し、
contoso_demo.cerをファイル名に置き換えます。certutil -addstore TrustedPeople contoso_demo.cercertutil -addstore /?を実行して、各パラメータの動作を確認できますが、簡単に言うと、次のようになります。-addstore: 証明書ストアに証明書を追加しますTrustedPeople: 証明書が配置されたストアを示します
エクスプローラーを使用します。
.pfxファイルのあるフォルダーに移動します。.pfxファイルをダブルクリックすると、証明書インポート ウィザードが表示されます- [
Local Machine] を選択して、[Next] をクリックします - ユーザー アカウント制御の管理者の昇格プロンプトが表示されたら同意して、[
Next] をクリックします - 秘密キーのパスワードがある場合には入力して、[
Next] をクリックします Place all certificates in the following storeを選択Browseをクリックして、(「信頼された発行元」ではなく)Trusted Peopleフォルダーを選択します- [
Next] をクリックして、次に [Finish] をクリックします
Trusted People ストアに証明書を追加したら、もう一度パッケージをインストールします。
これで、スタートメニューの「すべてのアプリ」リストにアプリが表示され、.resw / .pri ファイルの正しい情報が表示されます。 空白の文字列または文字列 ms-resource:... が表示されている場合は、何かが間違っています - 編集を再確認し、正しいことを確認してください。 スタート メニューでアプリを右クリックすると、アプリをタイルとしてピン留めし、そこに正しい情報が表示されていることを確認できます。
手順 1.3: サポートされている言語をさらに追加する
パッケージ マニフェストを変更し、初期の resources.resw ファイルを作成したら、追加の言語を容易に追加できます。
ローカライズされたその他のリソースを作成する
最初に、追加のローカライズされたリソース値を作成します。
Strings フォルダーで、適切な BCP-47 コードを使って、サポートする各言語のための、追加のフォルダーを作成します (たとえば、Strings\de-DE)。 これらの各フォルダー内に、翻訳されたリソース値を含む resources.resw ファイル (XML エディターまたは Visual Studio デザイナーを使用) を作成します。 ローカライズされた文字列がすでにどこかにあることを前提としており、それらを .resw ファイルにコピーするだけで済みます。このドキュメントでは、翻訳手順自体については説明しません。
たとえば、Strings\de-DE\resources.reswファイルは、次のようになります。強調表示されたテキストは en-US から変更されました。
<?xml version="1.0" encoding="utf-8"?>
<root>
<data name="ApplicationDescription">
<value>Contoso Demo app with localized resources (German)</value>
</data>
<data name="ApplicationDisplayName">
<value>Contoso Demo Sample (German)</value>
</data>
<data name="PackageDisplayName">
<value>Contoso Demo Package (German)</value>
</data>
<data name="PublisherDisplayName">
<value>Contoso Samples, DE</value>
</data>
<data name="TileShortName">
<value>Contoso (DE)</value>
</data>
</root>
次の手順では、de-DE と fr-FR の両方のリソースを追加したことを前提としていますが、どの言語でも同じパターンに従うことができます。
パッケージ マニフェストを更新してサポート言語をリストする
パッケージ マニフェストを更新して、アプリがサポートする言語をリストする必要があります。 Desktop App Converter は既定の言語を追加しますが、他の言語は明示的に追加する必要があります。 AppxManifest.xml ファイルを直接編集する場合、Resources ノードを次のように更新します。必要な要素を追加し、サポートする適切な言語を置き換え、一覧の最初のエントリが既定の (フォールバック) 言語となるようにします。
この例では、既定値は英語 (米国) で、ドイツ語 (ドイツ) とフランス語 (フランス) の両方が追加でサポートされています。
<Resources>
<Resource Language="EN-US" />
<Resource Language="DE-DE" />
<Resource Language="FR-FR" />
</Resources>
Visual Studio を使っている場合、何もする必要はありません。Package.appxmanifest には、特別な x-generate 値が含まれます。これによってビルド プロセスで、プロジェクトに含まれる (BCP-47 コードを使った名前のフォルダーに基づく) 言語が挿入されます。 これは実際のパッケージ マニフェストでは有効な値ではないことに注意してください。これは Visual Studio プロジェクトでのみ動作します。
<Resources>
<Resource Language="x-generate" />
</Resources>
ローカライズされた値を使用して再ビルドする
ここでもアプリケーションをビルドして展開できます。Windows で言語設定を変更すると、新しくローカライズされた値がスタート メニューに表示されます (言語を変更する方法については、以下の手順を参照してください)。
Visual Studio の場合も、Ctrl+Shift+B を使用してビルドし、プロジェクトを右クリックして Deploy を選択できます。
プロジェクトを手動でビルドする場合は、上記と同じ手順に従いますが、構成ファイルを作成するときに、アンダースコアで区切られた言語を既定の修飾子リスト (/dq) に追加します。 たとえば、前の手順で追加した英語、ドイツ語、フランス語のリソースをサポートするには、次のようにします。
makepri createconfig /cf ..\contoso_demo.xml /dq en-US_de-DE_fr-FR /pv 10.0 /o
これにより、テストに簡単に使用できる、指定されたすべての言語を含む PRI ファイルが作成されます。 リソースの合計サイズが小さい場合、または少数の言語のみをサポートしている場合、これは配送アプリで許容される可能性があります。これは、リソースのインストール/ダウンロード サイズを最小限に抑える利点が必要な場合にのみ、個別の言語パックを構築する追加作業を行う必要があります。
ローカライズされた値を使用してテストする
新しいローカライズされた変更をテストするには、Windows に新しい優先 UI 言語を追加するだけです。 言語パックをダウンロードしたり、システムを再起動したり、Windows UI 全体を外国語で表示したりする必要はありません。
Settingsアプリを実行します (Windows + I)- [https://resources.azure.com](
Time & language) に移動します - [https://resources.azure.com](
Region & language) に移動します - [
Add a language] をクリックします。 - 目的の言語を入力 (または選択) します (例:
DeutschまたはGerman)
- サブ言語がある場合は、目的の言語 (例:
Deutsch / Deutschland) を選択します。
- [言語] リスト で新しい言語を選択します。
- [
Set as default] をクリックします。
次に、スタート メニューを開き、アプリケーションを検索します。選択した言語のローカライズされた値が表示されます (他のアプリもローカライズされている可能性があります)。 ローカライズされた名前がすぐに表示されない場合は、スタート メニューのキャッシュが更新されるまで数分待ちます。 ネイティブ言語に戻すには、言語リストの既定の言語にします。
手順 1.4: パッケージ マニフェストの他の部分をローカライズする (省略可能)
パッケージ マニフェストの他のセクションをローカライズすることができます。 たとえば、アプリがファイル拡張子を処理する場合、マニフェストに windows.fileTypeAssociation 拡張があります。緑の強調表示のテキストを表示されているとおりに使い (これはリソースの参照です)、黄色の強調表示のテキストをアプリに固有の情報で置き換えます。
<Extensions>
<uap:Extension Category="windows.fileTypeAssociation">
<uap:FileTypeAssociation Name="default">
<uap:DisplayName>ms-resource:Resources/FileTypeDisplayName</uap:DisplayName>
<uap:Logo>Assets\StoreLogo.png</uap:Logo>
<uap:InfoTip>ms-resource:Resources/FileTypeInfoTip</uap:InfoTip>
<uap:SupportedFileTypes>
<uap:FileType ContentType="application/x-contoso">.contoso</uap:FileType>
</uap:SupportedFileTypes>
</uap:FileTypeAssociation>
</uap:Extension>
</Extensions>
Visual Studio のマニフェスト デザイナーを使って、この情報を追加することもできます。Declarations タブを使い、強調表示の値を記録します。
対応するリソース名を、各 .resw ファイルに追加し、強調表示のテキストをアプリに適切なテキストで置き換えます (サポートされているそれぞれの言語で行います)。
... existing content...
<data name="FileTypeDisplayName">
<value>Contoso Demo File</value>
</data>
<data name="FileTypeInfoTip">
<value>Files used by Contoso Demo App</value>
</data>
これにより、エクスプローラーなど、Windows シェルの一部に表示されます。
以前と同様にパッケージをビルドしてテストし、新しい UI 文字列を表示する必要がある新しいシナリオを実行します。
フェーズ 2: MRT を使用してリソースを識別して見つける
前のセクションでは、MRT を使用してアプリのマニフェスト ファイルをローカライズし、Windows シェルでアプリの名前やその他のメタデータを正しく表示できるようにする方法を示しました。 このためにコードを変更する必要はありませんでした。.reswファイルといくつかの追加ツールを使用するだけで済みました。 このセクションでは、MRT を使用して既存のリソース形式のリソースを検索し、既存のリソース処理コードを最小限の変更で使用する方法について説明します。
既存のファイル レイアウトとアプリケーションのコードについての想定
Win32 Desktop アプリをローカライズする方法は多数あるため、このホワイト ペーパーでは、特定の環境にマップする必要がある既存のアプリケーションの構造に関する前提条件を簡略化します。 MRT の要件に準拠するために、既存のコードベースまたはリソース レイアウトにいくつかの変更を加える必要がある場合があり、これらは主にこのドキュメントの範囲外です。
リソース ファイル レイアウト
この記事では、ローカライズされたリソースのすべてが同じファイル名を持ち (たとえば contoso_demo.exe.mui、contoso_strings.dll、contoso.strings.xml)、それらは BCP-47 名を持つ別のフォルダーに配置されている (en-US、de-DEなど) と想定します。 リソース ファイルの数、名前、ファイル形式や関連付けられている API などは関係ありません。重要なのは、すべての 論理 リソースが同じファイル名を持つ (ただし、異なる 物理 ディレクトリに配置される) ことです。
反例として、アプリケーションがファイル Resources と english_strings.dll を含む 1 つの french_strings.dll ディレクトリを持つフラットなファイル構造を使用する場合、MRT に適切にマップされません。 より良い構造は、サブディレクトリとファイル Resources と en\strings.dll を含む fr\strings.dll ディレクトリです。 また、同じベース ファイル名を使用することもできますが、埋め込み修飾子 (例: strings.lang-en.dll および strings.lang-fr.dll) を使用することもできますが、言語コードでディレクトリを使用する方が概念的に簡単であるため、焦点を当てます。
Note
この名前付け規則に従わない場合でも、MRT を使ってパッケージのメリットを活用することは可能ですが、より多くの作業が必要となります。
たとえば、アプリケーションには、UICommands フォルダーの下にレイアウトされた ui.txt という名前の単純なテキスト ファイルに一連のカスタム UI コマンド (ボタン ラベルなどに使用) が含まれる場合があります。
+ ProjectRoot |--+ Strings | |--+ en-US | | \--- resources.resw | \--+ de-DE | \--- resources.resw |--+ UICommands | |--+ en-US | | \--- ui.txt | \--+ de-DE | \--- ui.txt |--- AppxManifest.xml |--- ...rest of project...
リソースの読み込みコード
この記事では、コードの中のいずれかの時点で、ローカライズ リソースを含むファイルを検索し、読み込み、使用すると想定しています。 リソースの読み込みに使用される API、リソースの抽出に使用される API などは重要ではありません。 擬似コードでは、基本的に 3 つの手順があります。
set userLanguage = GetUsersPreferredLanguage()
set resourceFile = FindResourceFileForLanguage(MY_RESOURCE_NAME, userLanguage)
set resource = LoadResource(resourceFile)
// now use 'resource' however you want
MRT では、このプロセスの最初の 2 つの手順 (最適な候補リソースを決定する方法と検索方法) を変更するだけで済みます。 リソースの読み込み方法や使用方法を変更する必要はありません (ただし、リソースを利用する場合はそれを行うための機能が提供されます)。
たとえば、アプリケーションは Win32 API GetUserPreferredUILanguages、CRT 関数 sprintf、Win32 API CreateFile を使用して上記の 3 つの擬似コード関数を置き換え、 name=value ペアを探してテキスト ファイルを手動で解析します。 (詳細は重要ではありません。これは、MRT がリソースを見つけた後に処理するために使用される手法に影響がないことを示すためだけにあります)。
手順 2.1: MRT を使用してファイルを見つけるためのコード変更
リソースを検索するために MRT を使用するようにコードを切り替えることは困難ではありません。 それには、いくつかの WinRT 型と数行のコードを使用する必要があります。 使用するメインの種類は次のとおりです。
- ResourceContextは、現在アクティブな修飾子値のセット (言語、スケール ファクターなど) をカプセル化します。
- ResourceManager (.NET バージョンではなく WinRT バージョン)。PRI ファイルからすべてのリソースにアクセスできます。
- ResourceMapは、PRI ファイル内のリソースの特定のサブセット (この例では、ファイル ベースのリソースと文字列リソース) を表します。
- NamedResourceは、論理リソースとその考えられるすべての候補を表します。
- ResourceCandidate は、1 つの具象候補リソースを表します。
擬似コードでは、特定のリソース ファイル名 (上記のサンプルの UICommands\ui.txt など) を解決する方法は次のとおりです。
// Get the ResourceContext that applies to this app
set resourceContext = ResourceContext.GetForViewIndependentUse()
// Get the current ResourceManager (there's one per app)
set resourceManager = ResourceManager.Current
// Get the "Files" ResourceMap from the ResourceManager
set fileResources = resourceManager.MainResourceMap.GetSubtree("Files")
// Find the NamedResource with the logical filename we're looking for,
// by indexing into the ResourceMap
set desiredResource = fileResources["UICommands\ui.txt"]
// Get the ResourceCandidate that best matches our ResourceContext
set bestCandidate = desiredResource.Resolve(resourceContext)
// Get the string value (the filename) from the ResourceCandidate
set absoluteFileName = bestCandidate.ValueAsString
このコードでは、(実際のディスク上のファイルの配置にかかわらず) 特定の言語のフォルダー (UICommands\en-US\ui.txt など) を要求していないことに、特に注意してください。 代わりに論理ファイル名 UICommands\ui.txt を要求して、ディスク上の言語ディレクトリからの適切なファイルの選択を MRT に依存しています。
ここから、サンプル アプリでは、以前と同様に CreateFile を使用して absoluteFileName を読み込み、name=value のペアを解析できます。このロジックは、アプリで変更する必要はありません。 C# または C++/CX で記述する場合、実際のコードはこれよりそれほど複雑ではありません (実際、中間変数の多くは省略できます) - 以下の「.NET リソースの読み込み」セクションを参照してください。 C++/WRL ベースのアプリケーションは、WinRT API のアクティブ化と呼び出しに使用される低レベルの COM ベースの API のため、より複雑になりますが、実行する基本的な手順は同じです - 以下の「Win32 MUI リソースの読み込み」セクションを参照してください。
.NET リソースの読み込み
NETにはリソースを検索して読み込むためのメカニズム(「サテライトアセンブリ」と呼ばれる)が組み込まれているため、上記の合成例のように置き換える明示的なコードはありません - .NETでは、適切なディレクトリにリソースDLLが必要で、自動的に配置されます。 リソース パッケージを使ってアプリが MSIX または .appx としてパッケージ化された場合は、ディレクトリ構造はいくらか異なります。リソース ディレクトリは、メイン アプリケーション ディレクトリのサブディレクトリとして存在するのではなく、ピアとして存在します (または、ユーザーが使用する言語を指定していない場合には、まったく存在しません)。
たとえば、次のレイアウトの .NET アプリケーションで、すべてのファイルが MainApp フォルダーの下に存在するとします。
+ MainApp |--+ en-us | \--- MainApp.resources.dll |--+ de-de | \--- MainApp.resources.dll |--+ fr-fr | \--- MainApp.resources.dll \--- MainApp.exe
.appx への変換後、レイアウトはこのようになります。ここでは、en-US が既定の言語で、言語リストにドイツ語とフランス語が記載されています。
+ WindowsAppsRoot |--+ MainApp_neutral | |--+ en-us | | \--- MainApp.resources.dll | \--- MainApp.exe |--+ MainApp_neutral_resources.language_de | \--+ de-de | \--- MainApp.resources.dll \--+ MainApp_neutral_resources.language_fr \--+ fr-fr \--- MainApp.resources.dll
ローカライズされたリソースは、メインの実行可能ファイルのインストール場所の下のサブディレクトリに存在しなくなったため、組み込みの .NET リソース解決は失敗します。 さいわい、.NET には、失敗したアセンブリの読み込み試行を処理するための明確に定義されたメカニズム (AssemblyResolve イベント) があります。 MRT を使用する .NET アプリは、このイベントに登録し、不足しているアセンブリを .NET リソース サブシステムに提供する必要があります。
WinRT API を使用して .NET で使用されるサテライト アセンブリを検索する方法の簡潔な例を次に示します。提示されたコードは、最小限の実装を示すために意図的に圧縮されていますが、上記の擬似コードと密接にマップされており、渡された ResolveEventArgs は、検索する必要があるアセンブリの名前を提供します。 このコードの実行可能なバージョン (詳細なコメントとエラー処理を含む) は、GitHub の .NET アセンブリ リゾルバー サンプル の PriResourceRsolver.cs にあります。
static class PriResourceResolver
{
internal static Assembly ResolveResourceDll(object sender, ResolveEventArgs args)
{
var fullAssemblyName = new AssemblyName(args.Name);
var fileName = string.Format(@"{0}.dll", fullAssemblyName.Name);
var resourceContext = ResourceContext.GetForViewIndependentUse();
resourceContext.Languages = new[] { fullAssemblyName.CultureName };
var resource = ResourceManager.Current.MainResourceMap.GetSubtree("Files")[fileName];
// Note use of 'UnsafeLoadFrom' - this is required for apps installed with .appx, but
// in general is discouraged. The full sample provides a safer wrapper of this method
return Assembly.UnsafeLoadFrom(resource.Resolve(resourceContext).ValueAsString);
}
}
上記のクラスでは、アプリケーションのスタートアップ コードの早い段階で (ローカライズされたリソースを読み込む前に) 次のコードを追加します。
void EnableMrtResourceLookup()
{
AppDomain.CurrentDomain.AssemblyResolve += PriResourceResolver.ResolveResourceDll;
}
.NET ランタイムは、リソース DLL が見つからないたびに AssemblyResolve イベントを発生させ、その時点で、指定されたイベント ハンドラーが MRT を介して目的のファイルを検索し、アセンブリを返します。
Note
アプリが既に AssemblyResolve ハンドラーを他の目的で使用している場合、リソース解決のコードを、既存のコードと統合する必要があります。
Win32 MUI リソースの読み込み
Win32 MUI リソースの読み込みは基本的に .NET サテライト アセンブリの読み込みと同じですが、代わりに C++/CX または C++/WRL コードを使用します。 C++/CX を使用すると、上記の C# コードと密接に一致するはるかに簡単なコードが可能になりますが、C++ 言語拡張機能、コンパイラ スイッチ、および追加のランタイムを使用して、回避したい可能性があります。 その場合、C++/WRL を使用すると、より詳細なコードを犠牲にして、影響がはるかに低いソリューションが提供されます。 それでも、ATL プログラミング (または COM 全般) に精通している場合は、WRL に馴染みがあるはずです。
次のサンプル関数は、C++/WRL を使用して特定のリソース DLL を読み込み、通常の Win32 リソース API を使用してさらにリソースを読み込むために使用できる HINSTANCE を返す方法を示しています。 .NET ランタイムによって要求された言語で ResourceContext を明示的に初期化する C# サンプルとは異なり、このコードはユーザーの現在の言語に依存していることに注意してください。
#include <roapi.h>
#include <wrl\client.h>
#include <wrl\wrappers\corewrappers.h>
#include <Windows.ApplicationModel.resources.core.h>
#include <Windows.Foundation.h>
#define IF_FAIL_RETURN(hr) if (FAILED((hr))) return hr;
HRESULT GetMrtResourceHandle(LPCWSTR resourceFilePath, HINSTANCE* resourceHandle)
{
using namespace Microsoft::WRL;
using namespace Microsoft::WRL::Wrappers;
using namespace ABI::Windows::ApplicationModel::Resources::Core;
using namespace ABI::Windows::Foundation;
*resourceHandle = nullptr;
HRESULT hr{ S_OK };
RoInitializeWrapper roInit{ RO_INIT_SINGLETHREADED };
IF_FAIL_RETURN(roInit);
// Get Windows.ApplicationModel.Resources.Core.ResourceManager statics
ComPtr<IResourceManagerStatics> resourceManagerStatics;
IF_FAIL_RETURN(GetActivationFactory(
HStringReference(
RuntimeClass_Windows_ApplicationModel_Resources_Core_ResourceManager).Get(),
&resourceManagerStatics));
// Get .Current property
ComPtr<IResourceManager> resourceManager;
IF_FAIL_RETURN(resourceManagerStatics->get_Current(&resourceManager));
// get .MainResourceMap property
ComPtr<IResourceMap> resourceMap;
IF_FAIL_RETURN(resourceManager->get_MainResourceMap(&resourceMap));
// Call .GetValue with supplied filename
ComPtr<IResourceCandidate> resourceCandidate;
IF_FAIL_RETURN(resourceMap->GetValue(HStringReference(resourceFilePath).Get(),
&resourceCandidate));
// Get .ValueAsString property
HString resolvedResourceFilePath;
IF_FAIL_RETURN(resourceCandidate->get_ValueAsString(
resolvedResourceFilePath.GetAddressOf()));
// Finally, load the DLL and return the hInst.
*resourceHandle = LoadLibraryEx(resolvedResourceFilePath.GetRawBuffer(nullptr),
nullptr, LOAD_LIBRARY_AS_DATAFILE | LOAD_LIBRARY_AS_IMAGE_RESOURCE);
return S_OK;
}
フェーズ 3: リソース パックのビルド
すべてのリソースを含む「ファットパック」ができたので、ダウンロードとインストールのサイズを最小限に抑えるために、メインパッケージとリソースパッケージを別々に構築するための2つの方法があります。
- 既存のファットパックをバンドルジェネレーターツールに通すと、リソースパックが自動的に作成されます。 これは、ファット パックを既に生成しているビルド システムがあり、それを後処理してリソース パックを生成する場合に推奨される方法です。
- 個々のリソース パッケージを直接生成し、バンドルにビルドします。 これは、ビルド システムをより詳細に制御でき、パッケージを直接ビルドできる場合に推奨される方法です。
手順 3.1: バンドルを作成する
バンドル ジェネレーター ツールを使用します。
Bundle Generator ツールを使用するには、パッケージ用に作成された PRI 設定ファイルを手動で更新して <packaging> セクションを削除する必要があります。
Visual Studio を使っている場合、ファイル priconfig.packaging.xml と priconfig.default.xml を作成して、すべての言語をメイン パッケージにビルドする方法について詳しくは、「デバイスにリソースが必要かどうかにかかわらず、必ずリソースをデバイスにインストールする」をご覧ください。
ファイルを手動で編集する場合は、次の手順に従います。
正しいパス、ファイル名、言語を置き換えて、以前と同じ方法で構成ファイルを作成します。
makepri createconfig /cf ..\contoso_demo.xml /dq en-US_de-DE_es-MX /pv 10.0 /o作成
.xmlしたファイルを手動で開き、セクション全体<packaging&rt;を削除します (ただし、それ以外はすべてそのままにしておきます)。<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <resources targetOsVersion="10.0.0" majorVersion="1"> <!-- Packaging section has been deleted... --> <index root="\" startIndexAt="\"> <default> ... ...更新された構成ファイルと適切なディレクトリとファイル名を使用して、以前と同様に
.priファイルと.appxパッケージをビルドします (これらのコマンドの詳細については、上記を参照してください)。makepri new /pr . /cf ..\contoso_demo.xml /of ..\resources.pri /mf AppX /o makeappx pack /m AppXManifest.xml /f ..\resources.map.txt /p ..\contoso_demo.appx /oパッケージが作成されたら、適切なディレクトリとファイル名を使用して、次のコマンドを使用してバンドルを作成します。
BundleGenerator.exe -Package ..\contoso_demo.appx -Destination ..\bundle -BundleName contoso_demo
これで、最後の手順である署名に進むことができます (下をご覧ください)。
リソース パッケージの手動作成
リソース パッケージを手動で作成するには、個別 .pri の .appx ファイルをビルドするために少し異なるコマンド セットを実行する必要があります。これらはすべて、脂肪パッケージを作成するために上記で使用したコマンドと似ているため、最小限の説明が与えられます。 注: すべてのコマンドは、現在のディレクトリが AppXManifest.xml ファイルを含むディレクトリであることを前提としていますが、すべてのファイルは親ディレクトリに配置されます (必要に応じて別のディレクトリを使用できますが、これらのファイルでプロジェクト ディレクトリを汚染しないでください)。 常に、"Contoso" ファイル名を独自のファイル名に置き換えます。
次のコマンドを使用して、既定の言語のみを既定の修飾子として命名する、構成ファイルを作成します。この場合では
en-USです。makepri createconfig /cf ..\contoso_demo.xml /dq en-US /pv 10.0 /o次のコマンドを使用して、メイン パッケージの既定値
.priと.map.txtファイルに加えて、プロジェクトで見つかった各言語の追加のファイル セットを作成します。makepri new /pr . /cf ..\contoso_demo.xml /of ..\resources.pri /mf AppX /o次のコマンドを使用して、メイン パッケージ (実行可能コードと既定の言語リソースを含む) を作成します。 常に、必要に応じて名前を変更しますが、後でバンドルを簡単に作成できるようにパッケージを別のディレクトリに配置する必要があります (この例ではディレクトリを
..\bundle使用します)。makeappx pack /m .\AppXManifest.xml /f ..\resources.map.txt /p ..\bundle\contoso_demo.main.appx /oメインパッケージが作成されたら、追加の言語ごとに次のコマンドを一度使用します(つまり、前の手順で生成された言語マップファイルごとにこのコマンドを繰り返します)。 繰り返しになりますが、出力は別のディレクトリ(メインパッケージと同じディレクトリ)にある必要があります。 言語が
/fオプションと/pオプションの 両方 で指定されていることに注意してください。また、新しい/r引数の使い方 (リソース パッケージが必要であることを指定します) に注意してください。makeappx pack /r /m .\AppXManifest.xml /f ..\resources.language-de.map.txt /p ..\bundle\contoso_demo.de.appx /oバンドルディレクトリのすべてのパッケージを 1 つの
.appxbundleファイルに結合します。 新しい/dオプションは、バンドル内のすべてのファイルに使用するディレクトリを指定します (これが、前の手順で.appxファイルが別のディレクトリに配置されている理由です)。makeappx bundle /d ..\bundle /p ..\contoso_demo.appxbundle /o
パッケージのビルドの最後の手順は、署名です。
ステップ 3.2: バンドルに署名する
.appxbundle ファイルを(Bundle Generatorツールまたは手動で)作成すると、メインパッケージとすべてのリソースパッケージを含む1つのファイルが作成されます。 最後のステップは、Windowsがインストールするようにファイルに署名することです。
signtool sign /fd SHA256 /a /f ..\contoso_demo_key.pfx ..\contoso_demo.appxbundle
これにより、メイン パッケージとすべての言語固有のリソース パッケージを含む署名付き .appxbundle ファイルが生成されます。 パッケージ ファイルのようにダブルクリックすると、アプリに加えて、ユーザーの Windows 言語設定に基づいて適切な言語をインストールできます。
関連トピック
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示