レガシ アプリやゲームで Windows 10 のリソース管理システムを使用するUse the Windows 10 Resource Management System in a legacy app or game

.NET アプリや Win32 アプリは多くの場合、対象市場を拡大するため、さまざまな言語にローカライズされます。.NET and Win32 apps and games are often localized into different languages to expand their total addressable market. アプリのローカライズの価値提案の詳細については、「グローバリゼーションとローカライズ」をご覧ください。For more info about the value proposition of localizing your app, see Globalization and localization. .NET や Win32 のアプリやゲーム MSIX または AppX パッケージとしてパッケージ化、実行時のコンテキストに合わせたアプリのリソースを読み込むリソース管理システムを活用できます。By packaging your .NET or Win32 app or game as an MSIX or AppX package, you can leverage the Resource Management System to load app resources tailored to the run-time context. この詳細なトピックでは、この手法について説明します。This in-depth topic describes the techniques.

従来の Win32 アプリケーションをローカライズする方法はたくさんありますが、Windows 8 では新しいリソース管理システムが導入されました。このリソース管理システムは、さまざまなプログラミング言語やさまざまな種類のアプリケーションで動作し、ローカライズ機能を簡素化するだけでなく、さまざまな機能を提供します。There are many ways to localize a traditional Win32 application, but Windows 8 introduced a new resource-management system that works across programming languages, across application types, and provides functionality over and above simple localization. このトピックでは、このシステムを "MRT" と呼びます。This system will be referred to as "MRT" in this topic. 「モダン」という用語の使用は停止されましたが、MRT は従来 "Modern Resource Technology" を表していました。Historically, that stood for "Modern Resource Technology" but the term "Modern" has been discontinued. リソース マネージャーは、MRM (モダン リソース マネージャー) または PRI (パッケージ リソース インデックス) としても知られています。The resource manager might also be known as MRM (Modern Resource Manager) or PRI (Package Resource Index).

(たとえば、Microsoft Store) から MSIX ベースまたは AppX ベースの展開と組み合わせると、MRT 自動的に提供できる、特定のユーザーのほとんどの適用可能なリソース/デバイス、ダウンロードを最小化して、アプリケーションのサイズをインストールします。Combined with MSIX-based or AppX-based deployment (for example, from the Microsoft Store), MRT can automatically deliver the most-applicable resources for a given user / device which minimizes the download and install size of your application. ローカライズ コンテンツのサイズが大きなアプリケーションでは、これによって大きなサイズ削減効果があり、高度なゲームの場合では、数ギガバイトにも及ぶ削減効果となることがあります。This size reduction can be significant for applications with a large amount of localized content, perhaps on the order of several gigabytes for AAA games. さらに、Windows シェルと Microsoft Store でローカライズされて表示されることや、ユーザーの使用言語と利用可能なリソースが一致しない場合の自動フォールバック ロジックなども、MRT によるメリットの例です。Additional benefits of MRT include localized listings in the Windows Shell and the Microsoft Store, automatic fallback logic when a user's preferred language doesn't match your available resources.

このドキュメントでは、MRT のアーキテクチャの概要を説明し、レガシの Win32 アプリケーションを最小限のコード変更で MRT に移行するためのガイドを示します。This document describes the high-level architecture of MRT and provides a porting guide to help move legacy Win32 applications to MRT with minimal code changes. MRT への移行により、開発者にはさまざまなメリット (スケール ファクターやシステム テーマを使ったリソースのセグメント化など) があります。Once the move to MRT is made, additional benefits (such as the ability to segment resources by scale factor or system theme) become available to the developer. MRT ベースのローカライズは、UWP アプリケーションと、デスクトップ ブリッジ ("Centennial") によって処理される Win32 アプリケーションの両方で動作します。Note that MRT-based localization works for both UWP applications and Win32 applications processed by the Desktop Bridge (aka "Centennial").

多くの場合、既存のローカライズ形式とソース コードを引き続き使用しながら、MRT との統合を行い、実行時にリソースを解決して、ダウンロード サイズを最小化することができます。これはオールオアナッシングのアプローチではありません。In many situations, you can continue to use your existing localization formats and source code whilst integrating with MRT for resolving resources at runtime and minimizing download sizes - it's not an all-or-nothing approach. 各段階での作業とメリット、推定コストを次の表にまとめて示します。The following table summarizes the work and estimated cost/benefit of each stage. この表には、高解像度またはハイ コントラストのアプリケーション アイコンの提供などの、ローカライズ以外のタスクは含まれていません。This table doesn't include non-localization tasks, such as providing high-resolution or high-contrast application icons. タイル、アイコンなどへの複数のアセットの提供について詳しくは、「言語、スケール、ハイ コントラスト、その他の修飾子用にリソースを調整する」をご覧ください。For more info about providing multiple assets for tiles, icons, etc., See Tailor your resources for language, scale, high contrast, and other qualifiers.

仕事用Work メリットBenefit 推定コストEstimated cost
パッケージ マニフェストをローカライズします。Localize package manifest Windows シェルと Microsoft Store でローカライズ コンテンツが表示されるために必要な最小限の作業Bare minimum work required to have your localized content appear in the Windows Shell and in the Microsoft Store 小さなSmall
MRT を使ってリソースを識別して検索するUse MRT to identify and locate resources ダウンロードとインストールのサイズの最小化や、言語の自動フォールバックの前提条件Pre-requisite to minimizing download and install sizes; automatic language fallback Medium
リソース パッケージをビルドするBuild resource packs ダウンロードとインストールのサイズを最小化するための最後の手順Final step to minimize download and install sizes 小さなSmall
MRT リソース形式と API へ移行するMigrate to MRT resource formats and APIs 大幅に小さなファイル サイズ (既存のリソース テクノロジによる)Significantly smaller file sizes (depending on existing resource technology) 大規模ですLarge

概要Introduction

多くのアプリケーションには通常、アプリケーション コードから分離された、リソースと呼ばれるユーザー インターフェイス要素が含まれています (一方、値をハードコードする場合は、ソース コード自体に記述されます)。Most non-trivial applications contain user-interface elements known as resources that are decoupled from the application's code (contrasted with hard-coded values that are authored in the source code itself). ハードコードしないで、リソースを使用することが好ましい理由はいろいろあります。たとえば、開発者以外でも編集が容易であることもその 1 つです。最も重要なメリットの 1 つは、アプリケーションが実行時に、同じ論理リソースの異なる表現を選択できることです。There are several reasons to prefer resources over hard-coded values - ease of editing by non-developers, for example - but one of the key reasons is to enable the application to pick different representations of the same logical resource at runtime. たとえば、ボタンに表示するテキスト (またはアイコンに表示するイメージ) が、ユーザーの使用言語や、表示デバイスの種類、使用している支援技術などによって、異なる場合があります。For example, the text to display on a button (or the image to display in an icon) might differ depending on the language(s) the user understands, the characteristics of the display device, or whether the user has any assistive technologies enabled.

したがって、リソース管理テクノロジの主な目的は、実行時に、論理またはシンボリックなリソース名 (SAVE_BUTTON_LABELなど) の要求を、一連の候補 (たとえば、「Save」、「Speichern」、「保存」) の中から、実際に最適な (たとえば「保存」) に変換することです。Thus the primary purpose of any resource-management technology is to translate, at runtime, a request for a logical or symbolic resource name (such as SAVE_BUTTON_LABEL) into the best possible actual value (eg, "Save") from a set of possible candidates (eg, "Save", "Speichern", or "저장"). MRT はそのための機能を提供し、アプリケーションは、修飾子と呼ばれる、ユーザーの言語、ディスプレイのスケール ファクター、ユーザーが選択したテーマ、その他の環境の要因などの、さまざまな属性を使って、リソースの候補を識別することができます。MRT provides such a function, and enables applications to identify resource candidates using a wide variety of attributes, called qualifiers, such as the user's language, the display scale-factor, the user's selected theme, and other environmental factors. さらに MRT は、アプリケーションが必要とする、カスタムの修飾子をサポートします (たとえば、アプリケーションが、ゲスト ユーザーとアカウントを使ってログインしたユーザーに対して、別のグラフィック アセットを提供することができます。これを、アプリケーションのあらゆる部分にチェックのロジックを追加することなく、行えます)。MRT even supports custom qualifiers for applications that need it (for example, an application could provide different graphic assets for users that had logged in with an account vs. guest users, without explicitly adding this check into every part of their application). MRT は、文字列リソースとファイル ベースのリソース (外部データ、つまりファイル自体への参照として実装されている場合) の両方で動作します。MRT works with both string resources and file-based resources, where file-based resources are implemented as references to the external data (the files themselves).

Example

2 つのボタン (openButtonsaveButton) 上のテキスト ラベルと、ロゴ (logoImage) に使用する PNG ファイルを持つアプリケーションでの、簡単な例を次に示します。Here's a simple example of an application that has text labels on two buttons (openButton and saveButton) and a PNG file used for a logo (logoImage). テキスト ラベルは英語とドイツ語にローカライズされ、ロゴは通常のデスクトップ (100% スケール ファクター) と高解像度の電話 (300% スケール ファクター) 用に最適化されています。The text labels are localized into English and German, and the logo is optimized for normal desktop displays (100% scale factor) and high-resolution phones (300% scale factor). この図は、モデルの概念と概要を説明するためのものであり、実装に正確に対応するものではないことにご注意ください。Note that this diagram presents a high-level, conceptual view of the model; it does not map exactly to implementation.

この図で、アプリケーション コードは 3 つの論理リソース名を参照しています。In the graphic, the application code references the three logical resource names. 実行時に、擬似関数 GetResource は、MRT を使用して、リソース テーブル (PRI ファイルと呼ばれます) で、そのリソース名を検索し、環境条件 (ユーザーの言語とディスプレイのスケール ファクター) に基づいて、最適な候補を見つけます。At runtime, the GetResource pseudo-function uses MRT to look those resource names up in the resource table (known as PRI file) and find the most appropriate candidate based on the ambient conditions (the user's language and the display's scale-factor). ラベルの場合は、文字列が直接使用されます。In the case of the labels, the strings are used directly. ロゴ イメージの場合は、文字列がファイル名として解釈され、ファイルがディスクから読み取られます。In the case of the logo image, the strings are interpreted as filenames and the files are read off disk.

ユーザーが英語またはドイツ語以外の言語を話す場合、または 100% または 300% 以外、表示スケール ファクターが場合 MRT はフォールバック規則のセットに基づいて、「最も近い」一致する候補を取得 (を参照してくださいリソース管理システム詳細バック グラウンド)。If the user speaks a language other than English or German, or has a display scale-factor other than 100% or 300%, MRT picks the "closest" matching candidate based on a set of fallback rules (see Resource Management System for more background).

ロゴのイメージにもローカライズするために必要な埋め込みのテキストが含まれている場合に、MRT がなどの 1 つ以上の修飾子に対応したリソースをサポートしているメモ、ロゴは、次の 4 つの候補があります。EN/スケール 100、DE/スケール 100、EN/スケール-300、300-DE/スケール。Note that MRT supports resources that are tailored to more than one qualifier - for example, if the logo image contained embedded text that also needed to be localized, the logo would have four candidates: EN/Scale-100, DE/Scale-100, EN/Scale-300 and DE/Scale-300.

このドキュメントのセクションSections in this document

以下のセクションでは、アプリケーションを MRT と統合するために必要なタスクの概要を説明します。The following sections outline the high-level tasks required to integrate MRT with your application.

フェーズ 0:アプリケーション パッケージをビルドします。Phase 0: Build an application package

このセクションでは、既存のデスクトップ アプリケーションを、アプリケーション パッケージとしてビルドする方法について説明します。This section outlines how to get your existing Desktop application building as an application package. この段階では、MRT の機能は使用しません。No MRT features are used at this stage.

フェーズ 1:アプリケーション マニフェストをローカライズします。Phase 1: Localize the application manifest

このセクションでは、アプリケーションのマニフェストをローカライズする (これにより Windows Shell に正しく表示されるようになります) 方法について説明します。この段階では、引き続き、レガシのリソース形式と API を使用して、リソースのパッケージ化と検索を行っています。This section outlines how to localize your application's manifest (so that it appears correctly in the Windows Shell) whilst still using your legacy resource format and API to package and locate resources.

フェーズ 2:MRT を使ってリソースを識別して検索するPhase 2: Use MRT to identify and locate resources

このセクションでは、アプリケーション コード (および場合によってリソース レイアウト) を変更し、MRT を使用してリソースを検索する方法について説明します。この段階では、引き続き、既存のリソース形式と API を使用して、リソースの読み込みと使用を行っています。This section outlines how to modify your application code (and possibly resource layout) to locate resources using MRT, whilst still using your existing resource formats and APIs to load and consume the resources.

フェーズ 3:リソース パッケージをビルドするPhase 3: Build resource packs

このセクションでは、リソースを別のリソース パッケージに分離して、アプリのダウンロード (およびインストール) のサイズを最小化するために必要な、最終的な変更について説明します。This section outlines the final changes needed to separate your resources into separate resource packs, minimizing the download (and install) size of your app.

このドキュメントで扱わない内容Not covered in this document

上記の 0 ~ 3 のフェーズを完了すると、アプリケーション「バンドル」を Microsoft Store に送信できるし、するが、ダウンロードを最小限に抑える必要のないリソースを省略することでユーザーのサイズをインストールする必要が (例: 言語、話すこと)。After completing Phases 0-3 above, you will have an application "bundle" that can be submitted to the Microsoft Store and that will minimize the download and install size for users by omitting the resources they don't need (eg, languages they don't speak). 次の最後の手順を実行すると、アプリケーションのサイズと機能をさらに向上することができます。Further improvements in application size and functionality can be made by taking one final step.

フェーズ 4:MRT リソース形式と API へ移行するPhase 4: Migrate to MRT resource formats and APIs

このフェーズは、このドキュメントの対象範囲外です。このフェーズでは、MUI DLL や .NET リソース アセンブリなどの、レガシのリソース形式から、PRI ファイルに、リソース (特に文字列) を移行します。This phase is beyond the scope of this document; it entails moving your resources (particularly strings) from legacy formats such as MUI DLLs or .NET resource assemblies into PRI files. これにより、ダウンロードとインストールのサイズをさらに節約できます。This can lead to further space savings for download & install sizes. さらに、MRT の他の機能を活用でき、たとえば、スケール ファクターや、アクセシビリティ設定などに基づいて、イメージ ファイルのダウンロードとインストールを最小化できます。It also allows use of other MRT features such as minimizing the download and install of image files by based on scale factor, accessibility settings, and so on.

フェーズ 0:アプリケーション パッケージをビルドします。Phase 0: Build an application package

アプリケーションのリソースへの変更を行う前にまず、現在使っているパッケージ化とインストールのテクノロジを、UWP の標準のパッケージ化と展開のテクノロジに置き換える必要があります。Before you make any changes to your application's resources, you must first replace your current packaging and installation technology with the standard UWP packaging and deployment technology. これには 3 つの方法があります。There are three ways to do this:

  • 複雑なインストーラーでの大規模なデスクトップ アプリケーションがあったり、多数の OS の機能拡張ポイントを使用する場合は、UWP ファイル レイアウトを生成し、既存のアプリ インストーラー (MSI など) から情報をマニフェストに、Desktop App Converter ツールを使用できます。If you have a large desktop application with a complex installer or you utilize lots of OS extensibility points, you can use the Desktop App Converter tool to generate the UWP file layout and manifest information from your existing app installer (for example, an MSI).
  • 小さいのデスクトップ アプリケーション比較的少数のファイルまたは簡単なインストーラーとなしの拡張性フックを使用した場合は、ファイルのレイアウトを作成して、マニフェスト情報を手動で。If you have a smaller desktop application with relatively few files or a simple installer and no extensibility hooks, you can create the file layout and manifest information manually.
  • ソースから再構築しているアプリケーションを純粋な UWP アプリケーションを更新する場合は、Visual Studio で新しいプロジェクトを作成し、作業の多くを自動的に実行するための IDE に依存します。If you're rebuilding from source and want to update your app to be a pure UWP application, you can create a new project in Visual Studio and rely on the IDE to do much of the work for you.

使用する場合、 Desktop App Converterを参照してください、Desktop App Converter を使用してデスクトップ アプリケーションをパッケージ化変換プロセスの詳細についてはします。If you want to use the Desktop App Converter, see Package a desktop application using the Desktop App Converter for more information on the conversion process. デスクトップ コンバーター サンプルの完全なセットが見つかりますUWP にデスクトップ ブリッジ サンプル GitHub リポジトリします。A complete set of Desktop Converter samples can be found on the Desktop Bridge to UWP samples GitHub repo.

パッケージを手動で作成する場合は、アプリケーションのすべてのファイル (実行可能ファイルと、コンテンツがソース コードではなく) とパッケージ マニフェスト ファイル (.appxmanifest) が含まれるディレクトリ構造を作成する必要があります。If you want to manually create the package, you will need to create a directory structure that includes all your application's files (executables and content, but not source code) and a package manifest file (.appxmanifest). 例が記載されてこんにちは, World GitHub サンプル、という名前の実行可能ファイルのデスクトップを実行する基本的なパッケージ マニフェスト ファイルが、ContosoDemo.exeは次のように、場所、テキストを強調表示されているなります独自の値で置き換えられます。An example can be found in the Hello, World GitHub sample, but a basic package manifest file that runs the desktop executable named ContosoDemo.exe is as follows, where the highlighted text would be replaced by your own values.

<?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>

パッケージ マニフェスト ファイルとパッケージのレイアウトの詳細については、次を参照してください。アプリ パッケージのマニフェストします。For more information about the package manifest file and package layout, see App package manifest.

最後に、Visual Studio を新しいプロジェクトを作成し、既存のコード間で移行を使用している場合について作成「こんにちは, world」アプリします。Finally, if you're using Visual Studio to create a new project and migrate your existing code across, see Create a "Hello, world" app. 新しいプロジェクトの場合に、既存のコードを含めることができますが、純粋な UWP アプリとして実行するには、(特に、ユーザー インターフェイス) に大幅なコードの変更する必要があります可能性があります。You can include your existing code into the new project, but you will likely have to make significant code changes (particularly in the user interface) in order to run as a pure UWP app. それらの変更は、このドキュメントの対象範囲外です。These changes are outside the scope of this document.

フェーズ 1:マニフェストをローカライズします。Phase 1: Localize the manifest

手順 1.1:文字列の更新 (&)、マニフェスト内の資産Step 1.1: Update strings & assets in the manifest

フェーズ 0 (値コンバーターを提供、MSI から抽出された、または、マニフェストに手動で入力に基づく)、アプリケーションの基本的なパッケージ マニフェスト (.appxmanifest) ファイルを作成したのローカライズされた情報は含まれませんもサポートされます。高解像度の開始などの追加機能には、資産などが並べて表示します。In Phase 0 you created a basic package manifest (.appxmanifest) file for your application (based on values provided to the converter, extracted from the MSI, or manually entered into the manifest) but it will not contain localized information, nor will it support additional features like high-resolution Start tile assets, etc.

アプリケーションの名前と説明が正しくローカライズされたことを確認するには、するには、リソース ファイルのセット内の一部のリソースを定義し、それらを参照するパッケージのマニフェストを更新します。To ensure your application's name and description are correctly localized, you must define some resources in a set of resource files, and update the package manifest to reference them.

既定のリソース ファイルを作成するCreating a default resource file

最初の手順では、既定の言語 (たとえば、英語 (米国)) で既定のリソース ファイルを作成します。The first step is to create a default resource file in your default language (eg, US English). これは、テキスト エディターを使って手動で作成するか、または Visual Studio のリソース デザイナーによって行うことができます。You can do this either manually with a text editor, or via the Resource Designer in Visual Studio.

リソースを手動で作成する場合には:If you want to create the resources manually:

  1. resources.resw という XML ファイルを作成して、プロジェクトの Strings\en-us サブフォルダーに配置します。Create an XML file named resources.resw and place it in a Strings\en-us subfolder of your project. 既定の言語が英語 (米国) がない場合は、BCP 47 に適切なコードを使用します。Use the appropriate BCP-47 code if your default language is not US English.
  2. XML ファイルに次のコンテンツを追加します。使用する既定の言語で、強調表示されたテキストを、アプリのために適切なテキストに置き換えます。In the XML file, add the following content, where the highlighted text is replaced with the appropriate text for your app, in your default language.

注意

これらの文字列の一部の長の制限があります。There are restrictions on the lengths of some of these strings. 詳しくは、「VisualElements」をご覧ください。For more info, see 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 でデザイナーを使用する場合は:If you want to use the designer in Visual Studio:

  1. 作成、Strings\en-usプロジェクトのフォルダー (またはその他の言語は、必要に応じて) を追加し、新しい項目の、プロジェクトのルート フォルダーへの既定の名前を使用してresources.reswCreate the Strings\en-us folder (or other language as appropriate) in your project and add a New Item to the root folder of your project, using the default name of resources.resw. 選択してくださいリソース ファイル (.resw) なくリソース ディクショナリ-リソース ディクショナリは、XAML アプリケーションによって使用されるファイル。Be sure to choose Resources File (.resw) and not Resource Dictionary - a Resource Dictionary is a file used by XAML applications.
  2. デザイナーを使って次の文字列を入力します (同じ Names を使用し、Values をアプリケーションのために適切なテキストに置き換えます)。Using the designer, enter the following strings (use the same Names but replace the Values with the appropriate text for your application):

注意

常に直接キーを押して、XML を編集することができます、Visual Studio デザイナーを起動した場合F7します。If you start with the Visual Studio designer, you can always edit the XML directly by pressing F7. ただし、最小限の XML ファイルで開始する場合、さまざまな追加のメタデータが含まれていないため、デザイナーは、ファイルを認識しません。手動で編集する XML ファイルに、デザイナーが生成したファイルからスケルトンの XSD 情報をコピーすると、この問題を解決できます。But if you start with a minimal XML file, the designer will not recognize the file because it's missing a lot of additional metadata; you can fix this by copying the boilerplate XSD information from a designer-generated file into your hand-edited XML file.

マニフェストを更新してリソースを参照するUpdate the manifest to reference the resources

定義されている値を取得したら、.reswファイル、次の手順は、リソース文字列を参照するマニフェストを更新します。After you have the values defined in the .resw file, the next step is to update the manifest to reference the resource strings. ここでも、XML ファイルを直接編集するか、Visual Studio のマニフェスト デザイナーを利用できます。Again, you can edit an XML file directly, or rely on the Visual Studio Manifest Designer.

XML を直接編集する場合は、AppxManifest.xml ファイルを開き、強調表示された値に次の変更を行います。これは、アプリケーション固有ではなく、このテキストをそのまま使用します。If you are editing XML directly, open the AppxManifest.xml file and make the following changes to the highlighted values - use this exact text, not text specific to your application. これらのリソースの正確な名前を使用する必要はありません—独自に選択することができます—が内容に関係なく正確に一致する必要があります何であれ、.reswファイル。There is no requirement to use these exact resource names—you can choose your own—but whatever you choose must exactly match whatever is in the .resw file. これらの名前は .resw ファイルで作成した Names と一致し、ms-resource: スキームと Resources/ 名前空間のプレフィックスが付く必要があります。These names should match the Names you created in the .resw file, prefixed with the ms-resource: scheme and the Resources/ namespace.

注意

このスニペットから、マニフェストの多くの要素は省略されています - 何も削除しないでください。Many elements of the manifest have been omitted from this snippet - do not delete anything!

<?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>

.Appxmanifest ファイルを開くし、変更、Visual Studio のマニフェスト デザイナーを使用している場合、値を強調表示されている値、アプリケーション タブおよびパッケージ* タブ。If you are using the Visual Studio manifest designer, open the .appxmanifest file and change the highlighted values values in the *Application tab and the Packaging tab:

手順 1.2:PRI ファイルをビルド、MSIX パッケージでは、および確認することが動作Step 1.2: Build PRI file, make an MSIX package, and verify it's working

.pri ファイルをビルドし、アプリケーションを展開して、(既定の言語で) 正しい情報がスタート メニューに表示されることを確認します。You should now be able to build the .pri file and deploy the application to verify that the correct information (in your default language) is appearing in the Start Menu.

Visual Studio でビルドを行う場合は、Ctrl+Shift+B を押すとプロジェクトをビルドできます。次にプロジェクトを右クリックして、コンテキスト メニューから Deploy を選択します。If you're building in Visual Studio, simply press Ctrl+Shift+B to build the project and then right-click on the project and choose Deploy from the context menu.

手動で、構築する場合は、次の手順の構成ファイルを作成するをに従ってMakePRIツールを生成して、.priファイル自体 (詳細が記載されて手動アプリケーションのパッケージ化)。If you're building manually, follow these steps to create a configuration file for MakePRI tool and to generate the .pri file itself (more information can be found in Manual app packaging):

  1. 開発者コマンド プロンプトを開き、 Visual Studio 2017またはVisual Studio 2019 [スタート] メニューのフォルダー。Open a developer command prompt from the Visual Studio 2017 or Visual Studio 2019 folder in the Start menu.

  2. プロジェクトのルート ディレクトリに切り替えます (.appxmanifest ファイルを格納して、文字列フォルダー)。Switch to the project root directory (the one that contains the .appxmanifest file and the Strings folder).

  3. "Contoso_demo.xml" をプロジェクトに適した名前に置き換え、"en-US" をアプリの既定の言語に置き換えて (または必要に応じて "en-US" のままとして)、次のコマンドを入力します。Type the following command, replacing "contoso_demo.xml" with a name suitable for your project, and "en-US" with the default language of your app (or keep it en-US if applicable). 親ディレクトリに XML ファイルが作成されたに注意してください (いないプロジェクト ディレクトリ内) (他のディレクトリに必ず置き換えてください後でコマンドを選択することができます)、アプリケーションの一部ではないためです。Note the XML file is created in the parent directory (not in the project directory) since it's not part of the application (you can choose any other directory you want, but be sure to substitute that in future commands).

    makepri createconfig /cf ..\contoso_demo.xml /dq en-US /pv 10.0 /o
    

    makepri createconfig /?」と入力すると、各パラメーターの意味が表示されますが、主なパラメーターは次のとおりです。You can type makepri createconfig /? to see what each parameter does, but in summary:

    • /cf 構成ファイル名 (このコマンドの出力) を設定します。/cf sets the Configuration Filename (the output of this command)
    • /dq ここでは、言語、既定の修飾子を設定します。 en-US/dq sets the Default Qualifiers, in this case the language en-US
    • /pv このケースの Windows 10 では、プラットフォームのバージョンを設定します。/pv sets the Platform Version, in this case Windows 10
    • /o 存在する場合は、出力ファイルを上書きするように設定します。/o sets it to Overwrite the output file if it exists
  4. 構成ファイルが作成されました。MakePRI を再度実行して、ディスクにあるリソースを検索し、それを PRI ファイルにパッケージ化します。Now you have a configuration file, run MakePRI again to actually search the disk for resources and package them into a PRI file. "Contoso_demop.xml" を、前の手順で使った XML ファイル名に置き換えます。入力と出力の両方に、必ず親ディレクトリを指定します。Replace "contoso_demop.xml" with the XML filename you used in the previous step, and be sure to specify the parent directory for both input and output:

    makepri new /pr . /cf ..\contoso_demo.xml /of ..\resources.pri /mf AppX /o
    

    makepri new /? と入力すると、各パラメーターの意味が表示されますが、主なパラメーターは次のとおりです:You can type makepri new /? to see what each parameter does, but in a nutshell:

    • /pr (この例では、現在のディレクトリ) では、プロジェクトのルートを設定します。/pr sets the Project Root (in this case, the current directory)
    • /cf 前の手順で作成、構成ファイル名を設定します。/cf sets the Configuration Filename, created in the previous step
    • /of 出力ファイルを設定します。/of sets the Output File
    • /mf マッピング ファイルを作成します (そのため、後の手順でパッケージ内のファイルを除外しましたできます)/mf creates a Mapping File (so we can exclude files in the package in a later step)
    • /o 存在する場合は、出力ファイルを上書きするように設定します。/o sets it to Overwrite the output file if it exists
  5. 既定の言語リソース (たとえば en-US) を持つ .pri が作成されました。Now you have a .pri file with the default language resources (eg, en-US). 次のコマンドを実行して、正しく動作することを確認します。To verify that it worked correctly, you can run the following command:

    makepri dump /if ..\resources.pri /of ..\resources /o
    

    makepri dump /? と入力すると、各パラメーターの意味が表示されますが、主なパラメーターは次のとおりです:You can type makepri dump /? to see what each parameter does, but in a nutshell:

    • /if 入力ファイル名を設定します。/if sets the Input Filename
    • /of 出力ファイル名を設定 (.xmlが自動的に追加されます)/of sets the Output Filename (.xml will be appended automatically)
    • /o 存在する場合は、出力ファイルを上書きするように設定します。/o sets it to Overwrite the output file if it exists
  6. 最後に、 .\resources.xml をテキスト エディターで開き、<NamedResource> の値 (ApplicationDescriptionPublisherDisplayName など) が含まれること、さらに選択した既定の言語の <Candidate> が含まれることを確認します (ファイルの先頭には、その他のコンテンツがありますが、ここでは無視してください)。Finally, you can open ..\resources.xml in a text editor and verify it lists your <NamedResource> values (like ApplicationDescription and PublisherDisplayName) along with <Candidate> values for your chosen default language (there will be other content in the beginning of the file; ignore that for now).

マッピング ファイルを開くことができます.\resources.map.txt(プロジェクトのディレクトリの一部ではない PRI ファイルを含む)、プロジェクトに必要なファイルが含まれていることを確認します。You can open the mapping file ..\resources.map.txt to verify it contains the files needed for your project (including the PRI file, which is not part of the project's directory). マッピング ファイルには、 resources.resw ファイルへの参照は含まれていません。これは重要です。そのファイルの内容は既に PRI ファイルに埋め込まれているためです。Importantly, the mapping file will not include a reference to your resources.resw file because the contents of that file have already been embedded in the PRI file. ただし、イメージのファイル名などの他のリソースは含まれています。It will, however, contain other resources like the filenames of your images.

パッケージをビルドして署名するBuilding and signing the package

PRI ファイルがビルドされました。次はパッケージをビルドして署名します。Now the PRI file is built, you can build and sign the package:

  1. アプリ パッケージを作成するには、次のコマンドの置換を実行contoso_demo.appxMSIX/AppX の名前を持つファイルを作成して、ファイルを別のディレクトリを選択することを確認 (このサンプルは、親ディレクトリを使用しては、任意の場所必要がありますが可能にできますいないプロジェクト ディレクトリにあります)。To create the app package, run the following command replacing contoso_demo.appx with the name of the MSIX/AppX file you want to create and making sure to choose a different directory for the file (this sample uses the parent directory; it can be anywhere but should not be the project directory).

    makeappx pack /m AppXManifest.xml /f ..\resources.map.txt /p ..\contoso_demo.appx /o
    

    makeappx pack /? と入力すると、各パラメーターの意味が表示されますが、主なパラメーターは次のとおりです:You can type makeappx pack /? to see what each parameter does, but in a nutshell:

    • /m 使用するマニフェスト ファイルを設定します。/m sets the Manifest file to use
    • /f (前の手順で作成) を使用するファイルのマッピングを設定します。/f sets the mapping File to use (created in the previous step)
    • /p 出力を設定するパッケージ名/p sets the output Package name
    • /o 存在する場合は、出力ファイルを上書きするように設定します。/o sets it to Overwrite the output file if it exists
  2. パッケージを作成すると、署名する必要があります。After the package is created, it must be signed. 署名証明書を取得する最も簡単な方法は、Visual Studio で空のユニバーサル Windows プロジェクトを作成し、コピーは、.pfxが作成されるファイルを使用して手動で作成できます、MakeCertPvk2Pfx 」の説明に従ってユーティリティアプリ パッケージが署名証明書を作成する方法します。The easiest way to get a signing certificate is by creating an empty Universal Windows project in Visual Studio and copying the .pfx file it creates, but you can create one manually using the MakeCert and Pvk2Pfx utilities as described in How to create an app package signing certificate.

    重要

    署名証明書を手動で作成する場合は、ソース プロジェクトや、パッケージのソース、それ以外の場合、秘密キーを含む、パッケージの一部として含める取得可能性がありますよりも、別のディレクトリに、ファイルを配置することを確認してください!If you manually create a signing certificate, make sure you place the files in a different directory than your source project or your package source, otherwise it might get included as part of the package, including the private key!

  3. パッケージに署名するには、次のコマンドを使用します。To sign the package, use the following command. AppxManifest.xmlIdentity 要素で指定されている Publisher は、証明書の Subject と一致する必要があります (これは <PublisherDisplayName> 要素ではありません。それはユーザーに表示されるローカライズされた表示名です)。Note that the Publisher specified in the Identity element of the AppxManifest.xml must match the Subject of the certificate (this is not the <PublisherDisplayName> element, which is the localized display name to show to users). 通常と同様に、contoso_demo... のファイル名をプロジェクトに適した名前で置き換えます。さらに .pfx ファイルが現在のディレクトリにないことを確認します (これは非常に重要です。そうしない場合、プライベート署名キーを含めて、パッケージの一部として作成されてしまいます)。As usual, replace the contoso_demo... filenames with the names appropriate for your project, and (very important) make sure the .pfx file is not in the current directory (otherwise it would have been created as part of your package, including the private signing key!):

    signtool sign /fd SHA256 /a /f ..\contoso_demo_key.pfx ..\contoso_demo.appx
    

    signtool sign /? と入力すると、各パラメーターの意味が表示されますが、主なパラメーターは次のとおりです:You can type signtool sign /? to see what each parameter does, but in a nutshell:

    • /fd ファイルのダイジェスト アルゴリズム (SHA256 は AppX の既定値) を設定します。/fd sets the File Digest algorithm (SHA256 is the default for AppX)
    • /a 最適な証明書が自動的に選択します。/a will Automatically select the best certificate
    • /f 署名証明書を含む入力ファイルを指定します/f specifies the input File that contains the signing certificate

最後に、.appx ファイルをダブルクリックしてインストールします。またはコマンド ラインを使用する場合には、PowerShell プロンプトを開き、パッケージを含むディレクトリへ移動し、次のように入力します (contoso_demo.appx を使用するパッケージ名に置き換えます)。Finally, you can now double-click on the .appx file to install it, or if you prefer the command-line you can open a PowerShell prompt, change to the directory containing the package, and type the following (replacing contoso_demo.appx with your package name):

add-appxpackage contoso_demo.appx

証明書が信頼されていないというエラーが発生した場合、証明書が (ユーザー ストアではなく) コンピューターのストアに追加されていることを確認します。If you receive errors about the certificate not being trusted, make sure it is added to the machine store (not the user store). コンピューターのストアに証明書を追加するには、コマンドライン、または Windows エクスプローラーを使用します。To add the certificate to the machine store, you can either use the command-line or Windows Explorer.

コマンドラインを使用する場合:To use the command-line:

  1. Visual Studio 2017 または Visual Studio 2019 のコマンド プロンプトを管理者として実行します。Run a Visual Studio 2017 or Visual Studio 2019 command prompt as an Administrator.

  2. .cer ファイルを含むディレクトリに移動します (このディレクトリが、ソース ディレクトリまたはプロジェクト ディレクトリではないことを確認してください)Switch to the directory that contains the .cer file (remember to ensure this is outside of your source or project directories!)

  3. contoso_demo.cer を使用するファイル名と置き換えて、次のコマンドを入力します。Type the following command, replacing contoso_demo.cer with your filename:

    certutil -addstore TrustedPeople contoso_demo.cer
    

    certutil -addstore /? と入力すると、各パラメーターの意味が表示されますが、主なパラメーターは次のとおりです:You can run certutil -addstore /? to see what each parameter does, but in a nutshell:

    • -addstore 証明書ストアに証明書を追加します。-addstore adds a certificate to a certificate store
    • TrustedPeople ストアの証明書を配置することを示しますTrustedPeople indicates the store into which the certificate is placed

Windows エクスプローラーを使用する場合:To use Windows Explorer:

  1. .pfx ファイルが含まれているフォルダーに移動しますNavigate to the folder that contains the .pfx file
  2. .pfx ファイルをダブルクリックすると、証明書インポート ウィザードが表示されますDouble-click on the .pfx file and the Certicicate Import Wizard should appear
  3. 選択Local Machine をクリック NextChoose Local Machine and click Next
  4. 表示されたら、クリックすると、ユーザー アカウント制御管理者の昇格時のプロンプトを受け入れる NextAccept the User Account Control admin elevation prompt, if it appears, and click Next
  5. 、1 つを使用する必要がある場合は、秘密キーのパスワードを入力し、をクリックしてください NextEnter the password for the private key, if there is one, and click Next
  6. 選択します Place all certificates in the following storeSelect Place all certificates in the following store
  7. Browse をクリックして、(「信頼された発行元」ではなく) Trusted People フォルダーを選択しますClick Browse, and choose the Trusted People folder (not "Trusted Publishers")
  8. クリックNextFinishClick Next and then Finish

Trusted People ストアに証明書を追加したら、もう一度パッケージをインストールします。After adding the certificate to the Trusted People store, try installing the package again.

これでアプリは、.resw / .pri ファイルの正しい情報を使って、スタート メニューの [すべてのアプリ] のリストに表示されます。You should now see your app appear in the Start Menu's "All Apps" list, with the correct information from the .resw / .pri file. 空の文字列または ms-resource:... の文字列が表示された場合には、何かが間違っています。編集を再度確認し、すべて正しいかどうか確認します。If you see a blank string or the string ms-resource:... then something has gone wrong - double check your edits and make sure they're correct. スタート メニューでアプリを右クリックすると、タイルとしてピン留めすることができ、さらに適切な情報が表示されることを確認できます。If you right-click on your app in the Start Menu, you can Pin it as a tile and verify the correct information is displayed there also.

手順 1.3:サポートされている複数の言語を追加します。Step 1.3: Add more supported languages

パッケージ マニフェストと、最初に、変更を加えた後resources.reswファイルが作成されたら、その他の言語の追加は簡単です。After the changes have been made to the package manifest and the initial resources.resw file has been created, adding additional languages is easy.

追加のローカライズ リソースを作成するCreate additional localized resources

最初に、追加のローカライズ リソースの値を作成します。First, create the additional localized resource values.

Strings フォルダーで、適切な BCP-47 コードを使って、サポートする各言語のための、追加のフォルダーを作成します (たとえば、Strings\de-DE)。Within the Strings folder, create additional folders for each language you support using the appropriate BCP-47 code (for example, Strings\de-DE). 各フォルダー内に、(XML エディターまたは Visual Studio デザイナーを使用して) 翻訳されたリソースの値を含む resources.resw ファイルを作成します。Within each of these folders, create a resources.resw file (using either an XML editor or the Visual Studio designer) that includes the translated resource values. ここでは、既にローカライズされた文字列が利用可能であり、それを .resw ファイルにコピーして利用できるものと想定します。このドキュメントでは、翻訳の手順そのものは扱いません。It is assumed you already have the localized strings available somewhere, and you just need to copy them into the .resw file; this document does not cover the translation step itself.

たとえば、Strings\de-DE\resources.reswファイルは、次のようになります。強調表示されたテキストen-US から変更されました。For example, the Strings\de-DE\resources.resw file might look like this, with the highlighted text changed from 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-DEfr-FR の両方のリソースを追加したものと想定します。他の言語でも同じパターンで行うことができます。The following steps assume you added resources for both de-DE and fr-FR, but the same pattern can be followed for any language.

パッケージ マニフェストの言語のサポートされている一覧を更新します。Update the package manifest to list supported languages

パッケージ マニフェストは、アプリによって言語がサポートされている一覧を更新する必要があります。The package manifest must be updated to list the languages supported by the app. Desktop App Converter は、既定の言語を追加しますが、他の言語は明示的に追加する必要があります。The Desktop App Converter adds the default language, but the others must be added explicitly. AppxManifest.xml ファイルを直接編集する場合、Resources ノードを次のように更新します。必要な要素を追加し、サポートする適切な言語を置き換え、一覧の最初のエントリが既定の (フォールバック) 言語となるようにします。If you're editing the AppxManifest.xml file directly, update the Resources node as follows, adding as many elements as you need, and substituting the appropriate languages you support and making sure the first entry in the list is the default (fallback) language. この例では、既定値は英語 (米国) で、ドイツ語 (ドイツ)、フランス語 (フランス) が追加でサポートされます。In this example, the default is English (US) with additional support for both German (Germany) and French (France):

<Resources>
  <Resource Language="EN-US" />
  <Resource Language="DE-DE" />
  <Resource Language="FR-FR" />
</Resources>

Visual Studio を使っている場合、何もする必要はありません。Package.appxmanifest には、特別な x-generate 値が含まれます。これによってビルド プロセスで、プロジェクトに含まれる (BCP-47 コードを使った名前のフォルダーに基づく) 言語が挿入されます。If you are using Visual Studio, you shouldn't need to do anything; if you look at Package.appxmanifest you should see the special x-generate value, which causes the build process to insert the languages it finds in your project (based on the folders named with BCP-47 codes). 実際のパッケージ マニフェストの有効な値ではないことに注意してください。Visual Studio プロジェクトでのみ動作します。Note that this is not a valid value for a real package manifest; it only works for Visual Studio projects:

<Resources>
  <Resource Language="x-generate" />
</Resources>

ローカライズされた値でリビルドするRe-build with the localized values

ここで再度、アプリケーションのビルドを行ってデプロイすることができます。Windows で言語の選択を変更すると、新たにローカライズされた値がスタート メニューに表示されます (言語を変更する方法については、以下で説明します)。Now you can build and deploy your application, again, and if you change your language preference in Windows you should see the newly-localized values appear in the Start menu (instructions for how to change your language are below).

ここでも、Visual Studio では Ctrl+Shift+B を使ってビルドを行い、プロジェクトで右クリックして Deploy できます。For Visual Studio, again you can just use Ctrl+Shift+B to build, and right-click the project to Deploy.

プロジェクトを手動でビルドする場合は、上記と同じ手順に従いますが、構成ファイルを作成する際に、既定の修飾子の一覧 (/dq) にアンダー スコアで区切られた追加の言語を追加します。If you're manually building the project, follow the same steps as above but add the additional languages, separated by underscores, to the default qualifiers list (/dq) when creating the configuration file. たとえば、前の手順で追加された、英語、ドイツ語、フランス語のリソースをサポートするには:For example, to support the English, German, and French resources added in the previous step:

makepri createconfig /cf ..\contoso_demo.xml /dq en-US_de-DE_fr-FR /pv 10.0 /o

これにより、指定されたすべての言語を含む PRI ファイルが作成され、それをテスト用に簡単に使用できます。This will create a PRI file that contains all the specified languagesthat you can easily use for testing. リソースの合計サイズが小さい場合、または少数の言語のみをサポートする場合は、配布するアプリとしてこれで十分である場合もあります。リソースのインストールとダウンロードのサイズを最小化するメリットを必要とする場合のみ、言語ごとの個別の言語パックをビルドする追加の作業を行います。If the total size of your resources is small, or you only support a small number of languages, this might be acceptable for your shipping app; it's only if you want the benefits of minimizing install / download size for your resources that you need to do the additional work of building separate language packs.

ローカライズされた値をテストするTest with the localized values

新しくローカライズされた変更をテストするには、使用する新しい UI 言語を Windows に追加します。To test the new localized changes, you simply add a new preferred UI language to Windows. 言語パックをダウンロードしたり、システムを再起動したり、Windows UI 全体を他言語で表示させたりする必要はありません。There is no need to download language packs, reboot the system, or have your entire Windows UI appear in a foreign language.

  1. Settings アプリを実行します (Windows + I)Run the Settings app (Windows + I)
  2. 行きます Time & languageGo to Time & language
  3. 行きます Region & languageGo to Region & language
  4. をクリックします。 Add a languageClick Add a language
  5. 必要な言語を入力 (または選択) します (たとえば Deutsch または German)Type (or select) the language you want (eg Deutsch or German)
  • サブ言語がある場合は、必要なものを選びます (たとえば Deutsch / Deutschland)If there are sub-languages, choose the one you want (eg, Deutsch / Deutschland)
  1. 言語の一覧で新しい言語を選択しますSelect the new language in the language list
  2. をクリックします。 Set as defaultClick Set as default

スタート メニューを開き、作成したアプリケーションを検索します。選択した言語のローカライズされた値が表示されます (他のアプリもローカライズされて表示される場合があります)。Now open the Start menu and search for your application, and you should see the localized values for the selected language (other apps might also appear localized). ローカライズされた名前がすぐに表示されない場合は、スタート メニューのキャッシュが更新されるまで、数分待機します。If you don't see the localized name right away, wait a few minutes until the Start Menu's cache is refreshed. 元の言語に戻すには、言語の一覧で既定の言語を変更します。To return to your native language, just make it the default language in the language list.

手順 1.4:(省略可能) パッケージ マニフェストの他のパーツをローカライズします。Step 1.4: Localizing more parts of the package manifest (optional)

パッケージ マニフェストの他のセクションをローカライズすることができます。Other sections of the package manifest can be localized. たとえば、アプリがファイル拡張子を処理する場合、マニフェストに windows.fileTypeAssociation 拡張があります。緑の強調表示のテキストを表示されているとおりに使い (これはリソースの参照です)、黄色の強調表示のテキストをアプリに固有の情報で置き換えます。For example, if your application handles file-extensions then it should have a windows.fileTypeAssociation extension in the manifest, using the green highlighted text exactly as shown (since it will refer to resources), and replacing the yellow highlighted text with information specific to your application:

<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 タブを使い、強調表示の値を記録します。You can also add this information using the Visual Studio Manifest Designer, using the Declarations tab, taking note of the highlighted values:

対応するリソース名を、各 .resw ファイルに追加し、強調表示のテキストをアプリに適切なテキストで置き換えます (サポートされているそれぞれの言語で行います)。Now add the corresponding resource names to each of your .resw files, replacing the highlighted text with the appropriate text for your app (remember to do this for each supported language!):

... existing content...
<data name="FileTypeDisplayName">
  <value>Contoso Demo File</value>
</data>
<data name="FileTypeInfoTip">
  <value>Files used by Contoso Demo App</value>
</data>

これは、エクスプローラーなどの Windows シェルの一部で表示されます。This will then show up in parts of the Windows shell, such as File Explorer:

再び、ビルドを行い、パッケージをテストして、新しい UI 文字列が表示される新しいシナリオを試します。Build and test the package as before, exercising any new scenarios that should show the new UI strings.

フェーズ 2:MRT を使ってリソースを識別して検索するPhase 2: Use MRT to identify and locate resources

前のセクションでは、MRT を使用してアプリのマニフェスト ファイルをローカライズする方法を紹介しました。これによって、Windows シェルに、アプリの名前とその他のメタデータを正しく表示できるようになりました。The previous section showed how to use MRT to localize your app's manifest file so that the Windows Shell can correctly display the app's name and other metadata. これにはコードの変更は必要なく、.resw ファイルとその他のいくつかのツールのみを必要としました。No code changes were required for this; it simply required the use of .resw files and some additional tools. このセクションでは、MRT を使用して、既存のリソース形式のリソースを検索し、既存のリソース処理コードを最小限の変更で使用する方法を説明します。This section will show how to use MRT to locate resources in your existing resource formats and using your existing resource-handling code with minimal changes.

既存のファイル レイアウトとアプリケーションのコードについての想定Assumptions about existing file layout & application code

Win32 デスクトップ アプリをローカライズする方法は多数あるため、このホワイトペーパーでは、既存のアプリケーションの構造について、いつかの簡単な想定を置きます。この想定と実際のアプリの環境をマッピングしながら利用してください。Because there are many ways to localize Win32 Desktop apps, this paper will make some simplifying assumptions about the existing application's structure that you will need to map to your specific environment. MRT の要件に準拠するため、既存のコードベースやリソース レイアウトを変更する必要がある場合があります。それらの多くは、このドキュメントの対象範囲外となります。You might need to make some changes to your existing codebase or resource layout to conform to the requirements of MRT, and those are largely out of scope for this document.

リソース ファイルのレイアウトResource file layout

この記事では、すべてのローカライズされたリソースは、同じファイル名がある前提としています (例:contoso_demo.exe.muiまたはcontoso_strings.dllまたはcontoso.strings.xml) BCP 47 の名前を持つ別のフォルダーに配置されますが、(en-USde-DEなど。)。This article assumes your localized resources all have the same filenames (eg, contoso_demo.exe.mui or contoso_strings.dll or contoso.strings.xml) but that they are placed in different folders with BCP-47 names (en-US, de-DE, etc.). 問題があるリソース ファイルの数、その名前とは、どのようなファイルの形式ではありませんが、/Api が関連付けられているなど。すべての重要なことだけ論理リソースが同じファイル名 (別の配置が物理ディレクトリ)。It doesn't matter how many resource files you have, what their names are, what their file-formats / associated APIs are, etc. The only thing that matters is that every logical resource has the same filename (but placed in a different physical directory).

反対の例として、アプリケーションがフラットなファイル構造を使用していて、1 つの Resources ディレクトリに、english_strings.dllfrench_strings.dll が含まれている場合には、これは MRT にうまくマッピングされません。As a counter-example, if your application uses a flat file-structure with a single Resources directory containing the files english_strings.dll and french_strings.dll, it would not map well to MRT. 望ましい構造は、Resources ディレクトリにサブディレクトリがあり、そこにファイルが配置されている (たとえば en\strings.dllfr\strings.dll) 構造です。A better structure would be a Resources directory with subdirectories and files en\strings.dll and fr\strings.dll. strings.lang-en.dllstrings.lang-fr.dll などのように、同じ基本ファイル名を使用して、修飾子を埋め込むことも可能ですが、言語コードと同じディレクトリの使用がコンセプトとしてシンプルであり、ここではそれを使います。It's also possible to use the same base filename but with embedded qualifiers, such as strings.lang-en.dll and strings.lang-fr.dll, but using directories with the language codes is conceptually simpler so it's what we'll focus on.

注意

名前付け規則です。 このファイルを利用できない場合でも、MRT およびパッケージ化の利点を使用することも可能になります多くの作業が必要です。It is still possible to use MRT and the benefits of packaging even if you can't follow this file naming convention; it just requires more work.

たとえば、アプリケーションが、ui.txt という名前の単純なテキスト ファイルに含まれる、(ボタンのラベルなどに使用される) カスタムの UI コマンドのセットを持ち、UICommands フォルダーの下に配置される場合があります。For example, the application might have a set of custom UI commands (used for button labels etc.) in a simple text file named ui.txt, laid out under a UICommands folder:

+ ProjectRoot
|--+ Strings
|  |--+ en-US
|  |  \--- resources.resw
|  \--+ de-DE
|     \--- resources.resw
|--+ UICommands
|  |--+ en-US
|  |  \--- ui.txt
|  \--+ de-DE
|     \--- ui.txt
|--- AppxManifest.xml
|--- ...rest of project...

リソースの読み込みコードResource loading code

この記事では、ローカライズされたリソースを含むファイルを読み込んでしてそれを使用するコードのある時点で仮定します。This article assumes that at some point in your code you want to locate the file that contains a localized resource, load it, and then use it. リソースを読み込むために使用する API や、リソースを抽出するために使用する API などは重要ではありません。The APIs used to load the resources, the APIs used to extract the resources, etc. are not important. この疑似コードでは、基本的に 3 つの手順があります。In pseudocode, there are basically three steps:

set userLanguage = GetUsersPreferredLanguage()
set resourceFile = FindResourceFileForLanguage(MY_RESOURCE_NAME, userLanguage)
set resource = LoadResource(resourceFile) 
    
// now use 'resource' however you want

MRT では、このプロセスの最初の 2 つの手順のみを変更する必要があります。つまり、必要なリソース候補の決定と、その検索です。MRT only requires changing the first two steps in this process - how you determine the best candidate resources and how you locate them. リソースの読み込みと使用については、変更する必要はありません (ただし、それらを活用する場合は、それを行える機能を提供しています)。It doesn't require you to change how you load or use the resources (although it provides facilities for doing that if you want to take advantage of them).

たとえば、アプリケーションは、Win32 API GetUserPreferredUILanguages、CRT 関数 sprintf、Win32 API CreateFile を使用して、上記の 3 つの疑似コードの関数を置き換え、次にテキスト ファイルを手動で解析して、name=value のペアを検索できます。For example, the application might use the Win32 API GetUserPreferredUILanguages, the CRT function sprintf, and the Win32 API CreateFile to replace the three pseudocode functions above, then manually parse the text file looking for name=value pairs. (この詳細は重要ではありません。MRT は、リソースが検索された後の、リソースの処理に使用する手法には影響がないことを示すために説明しました)。(The details are not important; this is merely to illustrate that MRT has no impact on the techniques used to handle resources once they have been located).

手順 2.1:MRT を使用してファイルを検索するコードの変更Step 2.1: Code changes to use MRT to locate files

リソースの検索に MRT を使用するため、コードを切り替えることは難しくはありません。Switching your code to use MRT for locating resources is not difficult. いくつかの WinRT の種類と数行のコードを使う必要があります。It requires using a handful of WinRT types and a few lines of code. 主に使用される種類は次のとおりです。The main types that you will use are as follows:

  • ResourceContext 現在アクティブな修飾子の値のセット (言語、スケール ファクターなど) をカプセル化しますResourceContext, which encapsulates the currently active set of qualifier values (language, scale factor, etc.)
  • ResourceManager (.NETバージョンではなく、WinRT バージョン) PRI ファイルからすべてのリソースへのアクセスを実現しますResourceManager (the WinRT version, not the .NET version), which enables access to all the resources from the PRI file
  • ResourceMap PRI ファイル内のリソースの特定のサブセット (この例では、文字列リソースではなく、ファイル ベースのリソース) を表しますResourceMap, which represents a specific subset of the resources in the PRI file (in this example, the file-based resources vs. the string resources)
  • NamedResource 論理リソースとそのすべての候補を表しますNamedResource, which represents a logical resource and all its possible candidates
  • ResourceCandidate 1 つの具体的な候補リソースを表すResourceCandidate, which represents a single concrete candidate resource

あるリソースのファイル名 (たとえば、上のサンプルの UICommands\ui.txt など) を解決する方法は、疑似コードでは、次のようになります。In pseudo-code, the way you would resolve a given resource file name (like UICommands\ui.txt in the sample above) is as follows:

// 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 など) を要求していないことに、特に注意してください。Note in particular that the code does not request a specific language folder - like UICommands\en-US\ui.txt - even though that is how the files exist on-disk. 代わりに論理ファイル名 UICommands\ui.txt を要求して、ディスク上の言語ディレクトリからの適切なファイルの選択を MRT に依存しています。Instead, it asks for the logical filename UICommands\ui.txt and relies on MRT to find the appropriate on-disk file in one of the language directories.

これ以降、サンプル アプリは以前と同様に、CreateFile を使って absoluteFileName を読み込み、name=value ペアを解析できます。アプリ内のロジックの変更はまったく必要ありません。From here, the sample app could continue to use CreateFile to load the absoluteFileName and parse the name=value pairs just as before; none of that logic needs to change in the app. C# または C++/CX で記述している場合、実際のコードは、この擬似コード以上にそれほど複雑になることはありません (さらに多くの中間変数は省略できます)。下記の .NET リソースを読み込むのセクションをご覧ください。If you are writing in C# or C++/CX, the actual code is not much more complicated than this (and in fact many of the intermediate variables can be elided) - see the section on Loading .NET resources, below. C++/WRL ベースのアプリケーションでは、WinRT API のアクティブ化と呼び出しに使用される低レベルの COM ベースの API によってより複雑になりますが、基本的な手順は同じです。下記の Win32 MUI リソースを読み込むのセクションをご覧ください。C++/WRL-based applications will be more complex due to the low-level COM-based APIs used to activate and call the WinRT APIs, but the fundamental steps you take are the same - see the section on Loading Win32 MUI resources, below.

.NET リソースを読み込むLoading .NET resources

.NET には、リソースを検索して読み込むための組み込みのメカニズム (「サテライト アセンブリ」と呼ばれます) があるため、上記の合成の例のように、明示的なコードの置き換えは必要ありません.NET では、適切なディレクトリにリソース DLL が存在することのみが必要であり、それらは自動的に検索されます。Because .NET has a built-in mechanism for locating and loading resources (known as "Satellite Assemblies"), there is no explicit code to replace as in the synthetic example above - in .NET you just need your resource DLLs in the appropriate directories and they are automatically located for you. アプリは、MSIX としてパッケージ化または AppX リソース パックを使用して、ディレクトリ構造は若干異なるのではなくリソース ディレクトリは、メイン アプリケーション ディレクトリのサブディレクトリとそのピア (またはされるに存在しない場合、すべてのユーザー言語一覧に示された、ユーザー設定)。When an app is packaged as an MSIX or AppX using resource packs, the directory structure is somewhat different - rather than having the resource directories be subdirectories of the main application directory, they are peers of it (or not present at all if the user doesn't have the language listed in their preferences).

たとえば、次のレイアウトを持つ .NET アプリケーションを考えます。ここでは、すべてのファイルが MainApp フォルダーの下に存在しています。For example, imagine a .NET application with the following layout, where all the files exist under the MainApp folder:

+ MainApp
|--+ en-us
|  \--- MainApp.resources.dll
|--+ de-de
|  \--- MainApp.resources.dll
|--+ fr-fr
|  \--- MainApp.resources.dll
\--- MainApp.exe

AppX への変換後、レイアウトはこのようになります。ここでは、en-US が既定の言語で、言語リストにドイツ語とフランス語が記載されています。After conversion to AppX, the layout will look something like this, assuming en-US was the default language and the user has both German and French listed in their language list:

+ 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 リソースの解決が失敗します。Because the localized resources no longer exist in sub-directories underneath the main executable's install location, the built-in .NET resource resolution fails. さいわい、.NET は、失敗したアセンブリの読み込みの試行を処理するための、明確に定義されたメカニズムである、AssemblyResolve イベントを備えています。Luckily, .NET has a well-defined mechanism for handling failed assembly load attempts - the AssemblyResolve event. MRT を使用する .NET アプリは、このイベントに登録して、見つからなかったアセンブリを .NET リソース サブシステムに提供する必要があります。A .NET app using MRT must register for this event and provide the missing assembly for the .NET resource subsystem.

WinRT API を使用して、.NET で使われるサテライト アセンブリを検索する方法の簡単な例は次のとおりです。このコードは、最小限の実装を示すように、意図的に圧縮されていますが、上記の疑似コードによく対応しています。ここでは、渡されている ResolveEventArgs が検索する必要があるアセンブリの名前を提供します。A concise example of how to use the WinRT APIs to locate satellite assemblies used by .NET is as follows; the code as-presented is intentionally compressed to show a minimal implementation, although you can see it maps closely to the pseudo-code above, with the passed-in ResolveEventArgs providing the name of the assembly we need to locate. このコードの実行可能なバージョン (詳細なコメントとエラー処理を含む) は、GitHub の .NET アセンブリ リゾルバー サンプルPriResourceRsolver.cs にあります。A runnable version of this code (with detailed comments and error-handling) can be found in the file PriResourceRsolver.cs in the .NET Assembly Resolver sample on GitHub.

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);
  }
}

上記のクラスでは、次のコードを事前にアプリケーションのスタートアップ コードのどこかに (いずれかのローカライズ リソースを読み込む前に) 追加する必要があります。Given the class above, you would add the following somewhere early-on in your application's startup code (before any localized resources would need to load):

void EnableMrtResourceLookup()
{
  AppDomain.CurrentDomain.AssemblyResolve += PriResourceResolver.ResolveResourceDll;
}

.NET ランタイムは、リソース DLL が見つからない場合には、AssemblyResolve イベントを発生させます。その場合、提供されたイベント ハンドラーは、MRT を使って必要なファイルを検索し、アセンブリを返します。The .NET runtime will raise the AssemblyResolve event whenever it can't find the resource DLLs, at which point the provided event handler will locate the desired file via MRT and return the assembly.

注意

アプリが既にある場合、AssemblyResolveハンドラーなどの目的に、既存のコードとリソース解決のコードを統合する必要があります。If your app already has an AssemblyResolve handler for other purposes, you will need to integrate the resource-resolving code with your existing code.

Win32 MUI リソースを読み込むLoading Win32 MUI resources

Win32 MUI リソースの読み込みは、.NET サテライト アセンブリの読み込みと基本的には同じですが、C++/CX または C++/WRL コードを使います。Loading Win32 MUI resources is essentially the same as loading .NET Satellite Assemblies, but using either C++/CX or C++/WRL code instead. C++/CX を使うと、コードがよりシンプルになり、上記の C# にとても近くなりますが、C++ 言語拡張、コンパイラ スイッチ、その他のランタイム オーバーヘッドを使うため、これはあまり望ましくない場合があります。Using C++/CX allows for much simpler code that closely matches the C# code above, but it uses C++ language extensions, compiler switches, and additional runtime overheard you might wish to avoid. その場合は、C++/WRL を使うと、コードは冗長になりますが、影響のより小さいソリューションとなります。If that is the case, using C++/WRL provides a much lower-impact solution at the cost of more verbose code. それでも、ATL プログラミング (または COM 一般) に慣れている場合には、WRL がなじみやすい選択となります。Nevertheless, if you are familiar with ATL programming (or COM in general) then WRL should feel familiar.

次のサンプル関数は、C++/WRL を使って、特定のリソース DLL を読み込み、HINSTANCE を返します。これにより、通常の Win32 リソース API を使って、さらにリソースを読み込むことができます。The following sample function shows how to use C++/WRL to load a specific resource DLL and return an HINSTANCE that can be used to load further resources using the usual Win32 resource APIs. .NET ランタイムに要求された言語を使って明示的に ResourceContext を初期化する C# のサンプルとは異なり、このコードはユーザーの現在の言語に依存しています。Note that unlike the C# sample that explicitly initializes the ResourceContext with the language requested by the .NET runtime, this code relies on the user's current language.

#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:リソース パックの構築Phase 3: Building resource packs

これで、すべてのリソースを含む "ファット" パッケージができました。ダウンロードとインストールのサイズを最小化するために、メイン パッケージとリソース パッケージを分離してビルドするには、2 つの方法があります。Now that you have a "fat pack" that contains all resources, there are two paths towards building separate main package and resource packages in order to minimize download and install sizes:

  • 既存のファット パッケージを使い、Bundle Generator ツールを実行して、自動的にリソース パッケージを作成します。Take an existing fat pack and run it through the Bundle Generator tool to automatically create resource packs. これは、既にファット パッケージを作成するビルド システムがあり、ポスト プロセスとしてリソース パッケージを生成する場合に、推奨されるアプローチです。This is the preferred approach if you have a build system that already produces a fat pack and you want to post-process it to generate the resource packs.
  • 直接、個々のリソース パッケージを作成し、それらをビルドしてバンドルを作成します。Directly produce the individual resource packages and build them into a bundle. これは、ビルド システムをより細かく制御して、パッケージを直接作成する場合に、推奨されるアプローチです。This is the preferred approach if you have more control over your build system and can build the packages directly.

手順 3.1:バンドルの作成Step 3.1: Creating the bundle

Bundle Generator ツールを使用するUsing the Bundle Generator tool

Bundle Generator ツールを使用するには、パッケージ用に作成した PRI 構成ファイルを手動で更新して、<packaging> セクションを削除する必要があります。In order to use the Bundle Generator tool, the PRI config file created for the package needs to be manually updated to remove the <packaging> section.

Visual Studio を使用している場合を参照してくださいリソースがデバイスでの必要かどうかに関係なく、デバイスにインストールされていることを確認ファイルを作成して、メインのパッケージにすべての言語を構築する方法についてはpriconfig.packaging.xmlpriconfig.default.xmlします。If you're using Visual Studio, refer to Ensure that resources are installed on a device regardless of whether a device requires them for information on how to build all languages into the main package by creating the files priconfig.packaging.xml and priconfig.default.xml.

ファイルを手動で編集する場合は、次の手順に従います。If you're manually editing files, follow these steps:

  1. 正しいパス、ファイル名、言語を置き換えて、以前と同じ方法で構成ファイルを作成します。Create the config file the same way as before, substituting the correct path, file name and languages:

    makepri createconfig /cf ..\contoso_demo.xml /dq en-US_de-DE_es-MX /pv 10.0 /o
    
  2. 作成された .xml ファイルを手動で開き、&lt;packaging&rt; セクション全体を削除します (それ以外はそのまま残します)。Manually open the created .xml file and delete the entire &lt;packaging&rt; section (but keep everything else intact):

    <?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>
        ...
        ...
    
  3. 更新された構成ファイルと適切なディレクトリとファイル名を使って、以前と同じ方法で .pri ファイルと .appx パッケージをビルドします (これらのコマンドについて詳しくは上記をご覧ください)。Build the .pri file and the .appx package as before, using the updated configuration file and the appropriate directory and file names (see above for more information on these commands):

    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
    
  4. パッケージが作成された後は、次のコマンドを使用して、適切なディレクトリとファイル名を使用して、バンドルを作成します。AFter the package has been created, use the following command to create the bundle, using the appropriate directory and file names:

    BundleGenerator.exe -Package ..\contoso_demo.appx -Destination ..\bundle -BundleName contoso_demo
    

今すぐ署名 (以下参照)、最後の手順に移動できます。Now you can move to the final step, signing (see below).

手動でリソース パッケージを作成するManually creating resource packages

リソース パッケージを手動で作成する場合は、やや異なるコマンドのセットを実行して、別の .pri ファイルと .appx ファイルをビルドする必要があります。これらはすべて、上でファット パッケージの作成に使用したコマンドに似ていますので、簡単な説明にとどめます。Manually creating resource packages requires running a slightly different set of commands to build separate .pri and .appx files - these are all similar to the commands used above to create fat packages, so minimal explanation is given. 注:すべてのコマンドは、現在のディレクトリにディレクトリがある前提としています格納している、AppXManifest.xmlファイルがすべてのファイルは、(を使用できますの別のディレクトリが必要に応じて、プロジェクト ディレクトリのいずれかを煩雑べきではない場合、親ディレクトリに配置されます。これらのファイル)。Note: All the commands assume that the current directory is the directory containing the AppXManifest.xml file, but all files are placed into the parent directory (you can use a different directory, if necessary, but you shouldn't pollute the project directory with any of these files). いつもと同様に、"Contoso" のファイル名を独自のファイル名で置き換えます。As always, replace the "Contoso" filenames with your own file names.

  1. 次のコマンドを使用して、既定の言語のみを既定の修飾子として命名する、構成ファイルを作成します。この場合では en-US です。Use the following command to create a config file that names only the default language as the default qualifier - in this case, en-US:

    makepri createconfig /cf ..\contoso_demo.xml /dq en-US /pv 10.0 /o
    
  2. 次のコマンドを使って、メイン パッケージの既定の .pri ファイルと.map.txt ファイルを作成し、さらにプロジェクトの各言語の追加のファイルのセットを作成します。Create a default .pri and .map.txt file for the main package, plus an additional set of files for each language found in your project, with the following command:

    makepri new /pr . /cf ..\contoso_demo.xml /of ..\resources.pri /mf AppX /o
    
  3. 次のコマンドを使って、メイン パッケージを作成します (これには実行可能コードと既定の言語リソースが含まれています)。Use the following command to create the main package (which contains the executable code and default language resources). いつもと同様に、必要に応じて名前を変更します。後でバンドルの作成が容易になるように、パッケージは別のディレクトリに配置する必要があります (この例では、 .\bundle ディレクトリを使います)。As always, change the name as you see fit, although you should put the package in a separate directory to make creating the bundle easier later (this example uses the ..\bundle directory):

    makeappx pack /m .\AppXManifest.xml /f ..\resources.map.txt /p ..\bundle\contoso_demo.main.appx /o
    
  4. メイン パッケージが作成されたら、次のコマンドを追加言語ごとに 1 回ずつ使います (つまり、前の手順で生成された各言語マップ ファイルに、このコマンドを繰り返します)。After the main package has been created, use the following command once for each additional language (ie, repeat this command for each language map file generated in the previous step). ここでも、出力は別のディレクトリ (メイン パッケージと同じディレクトリ) にする必要があります。Again, the output should be in a separate directory (the same one as the main package). 言語が /f オプションと /p オプションの 両方 で指定されていることに注意してください。また、新しい /r 引数の使い方 (リソース パッケージが必要であることを指定します) に注意してください。Note the language is specified both in the /f option and the /p option, and the use of the new /r argument (which indicates a Resource Package is desired):

    makeappx pack /r /m .\AppXManifest.xml /f ..\resources.language-de.map.txt /p ..\bundle\contoso_demo.de.appx /o
    
  5. バンドル ディレクトリからのすべてのパッケージをまとめて、1 つの .appxbundle ファイルを作成します。Combine all the packages from the bundle directory into a single .appxbundle file. 新しい /d オプションは、バンドル内のすべてのファイルが使用するディレクトリを指定します (前の手順で .appx ファイルを別のディレクトリに配置したのはこのためです)。The new /d option specifies the directory to use for all the files in the bundle (this is why the .appx files are put into a separate directory in the previous step):

    makeappx bundle /d ..\bundle /p ..\contoso_demo.appxbundle /o
    

パッケージを構築するための最後の手順を署名します。The final step to building the package is signing.

手順 3.2:バンドルの署名Step 3.2: Signing the bundle

(Bundle Generator ツールを使うか、または手動で) .appxbundle を作成したら、メイン パッケージとすべてのリソース パッケージを含む、1 つのファイルが作成されます。 Once you have created the .appxbundle file (either through the Bundle Generator tool or manually) you will have a single file that contains the main package plus all the resource packages. 最後の手順は、ファイルに署名を行い、Windows がインストールできるようにすることです。The final step is to sign the file so that Windows will install it:

signtool sign /fd SHA256 /a /f ..\contoso_demo_key.pfx ..\contoso_demo.appxbundle

これによって、メイン パッケージとすべての言語固有のリソース パッケージを含む、署名済みの .appxbundle ファイルが作成されます。This will produce a signed .appxbundle file that contains the main package plus all the language-specific resource packages. これはパッケージ ファイルと同様にダブルクリックでき、それによって、アプリに加えて、ユーザーの Windows の言語設定に基づく適切な言語をインストールすることができます。It can be double-clicked just like a package file to install the app plus any appropriate language(s) based on the user's Windows language preferences.