翻訳への提案を行います
 
他のユーザーによる提案:

progress indicator
他の提案はありません。
クリックして評価とフィードバックをお寄せください
MSDN
MSDN ライブラリ
.NET 開発
.NET Framework 4
.NET Framework の基本開発
 サテライト アセンブリの作成
すべて縮小/すべて展開 すべて縮小
コンテンツの表示:   英語と日本語を並べて表示コンテンツの表示: 英語と日本語を並べて表示
.NET Framework 4
Creating Satellite Assemblies

The hub and spoke model described in the Packaging and Deploying Resources topic is the recommended design implementation for developing applications with resources.

The hub and spoke model requires that you place resources in specific locations, so that they can be easily located and used. If you do not compile and name resources as expected, or if you do not place them in the correct locations, the common language runtime will not be able to locate them. As a result, the runtime uses the default resource set. For more information on resource names, see CultureInfo Class or Packaging and Deploying Resources.

Use the Assembly Linker (Al.exe) to compile .resources files into satellite assemblies. Al.exe creates an assembly from the .resources files that you specify. By definition, satellite assemblies can only contain resources. They cannot contain any executable code.

The following Al.exe command creates a satellite assembly for the application MyApp from the file strings.de.resources.

al /t:lib /embed:strings.de.resources /culture:de /out:MyApp.resources.dll

The following Al.exe command also creates a satellite assembly for the application MyApp from the file strings.de.resources. The /template option causes the satellite assembly to inherit assembly metadata from the parent assembly MyApp.dll.

al /t:lib /embed:strings.de.resources /culture:de /out:MyApp.resources.dll
/template:MyApp.dll

The following table explains the Al.exe options used in these examples in more detail.

Option

Description

/t:lib

The /t option specifies that your satellite assembly is compiled to a library (.dll ) file. A satellite assembly cannot be executed because it does not contain code and is not an application's main assembly. Therefore, you must save satellite assemblies as DLLs.

/embed:strings.de.resources

The /embed option specifies the name of the source file to use when Al.exe compiles the assembly. Note that you can embed multiple .resources files in a satellite assembly. However, if you are following the hub and spoke model, you must compile one satellite assembly for each culture. You can, however, create separate .resources files for strings and objects.

/culture:de

The /culture option specifies the culture of the resource to compile. The runtime uses this information when it searches for the resources for a specified culture. If you omit this option, Al.exe still compiles the resource, but the runtime will not be able to find it when a user requests it.

/out:MyApp.resources.dll

The /out option specifies the name of the output file. The name must follow the naming standard baseName.resources.extension, where the baseName is the name of the main assembly, and the extension is a viable extension (such as .dll). Note that the runtime is not able to determine the culture of a satellite assembly based on its output file name. Therefore it is important to specify a culture with the /culture option described above.

/template:filename

The /template option specifies an assembly from which to inherit all assembly metadata, except the culture field. The assembly that the satellite assembly inherits from must have a strong name.

For a complete list of the options available with Al.exe, see Assembly Linker (Al.exe).

If you want to install satellite assemblies into the global assembly cache, they must have strong names. Strong-named assemblies are signed with a valid public/private key pair. For more information on strong names, see Strong-Named Assemblies.

When you are developing an application, it is unlikely that you will have access to the final public/private key pair. In order to install a satellite assembly in the global assembly cache and ensure that it works as expected, you can use a technique called delayed signing. When you delay sign an assembly, you reserve space in the file for the strong name signature at build time. The actual signing is delayed until a later date when the final public/private key pair is available.

Obtaining the Public Key

To delay sign an assembly, you must have access to the public key. You can either obtain the real public key from the organization in your company that will do the eventual signing, or create a public key using the Strong Name Tool (Sn.exe).

The following Sn.exe command creates a test public/private key pair and saves it in the file TestKeyPair.snk. The –k option specifies to Sn.exe to create a new key pair and save it in the specified file.

sn –k TestKeyPair.snk 

You can extract the public key from the file containing the test key pair. The following command extracts the public key from TestKeyPair.snk and saves it in PublicKey.snk.

sn –p TestKeyPair.snk PublicKey.snk

Delay Signing an Assembly

Once you have obtained or created the public key, use the Assembly Linker (Al.exe) to compile the assembly and specify delayed signing.

The following Al.exe command creates a strong-named satellite assembly for the application MyApp from the strings.ja.resources file.

al /t:lib /embed:strings.ja.resources /culture:ja /out:MyApp.resources.dll /delay+ /keyfile:PublicKey.snk

The /delay+ option specifies to delay sign the assembly. The /keyfile: option specifies the name of the key file containing the public key to use to delay sign the assembly.

For more information on delayed signing, see Delay Signing an Assembly.

Note that strong-named assemblies contain version information that the runtime uses to determine which assembly to use to meet a binding request. For more information on this topic, see Assembly Versioning.

Re-signing an Assembly

At some later date, a delay-signed satellite assembly must be re-signed with the real key pair. You can do this using Sn.exe.

The following Sn.exe command signs MyApp.resources.dll with the real key pair stored in the file RealKeyPair.snk. The –R option specifies to Sn.exe to re-sign a previously signed or delay-signed assembly.

sn –R MyApp.resources.dll RealKeyPair.snk 

Installing a Satellite Assembly in the Global Assembly Cache

The global assembly cache is the first location the runtime searches for resources in the resource fallback process. For more information, see the "Resource Fallback Process" subtopic in the Packaging and Deploying Resources topic. Therefore, it is important to know how to install resources into the global assembly cache. A satellite assembly that you have compiled with a strong name is ready to install in the global assembly cache. You can install assemblies into the cache using the Global Assembly Cache Tool (Gacutil.exe).

The following Gacutil.exe command installs MyApp.resources.dll into the global assembly cache.

gacutil /i:MyApp.resources.dll

The /i option specifies to Gacutil.exe to install the specified assembly into the global assembly cache. As a result of this command, an entry is placed in the cache, which allows entries in this .resources file to be accessed. After being installed in the cache, the specified resource is available to all applications that are designed to use it.

After you have compiled your satellite assemblies, they all have the same name. The runtime differentiates between them based upon the culture specified at compile time with Al.exe's /culture option and by each assembly's directory location. You must place your satellite assemblies in expected directory locations.

The following illustration shows a sample directory structure and location requirements for applications that you are not installing in the global assembly cache. The items with .txt and .resources file extensions will not ship with the final application. These are the intermediate resource files used to create the final satellite resource assemblies. In this example, you could substitute .resx files for the .txt files. The .resx files are the only type of intermediate resource file that can contain objects.

Satellite assembly directory

Satellite assemblies
NoteNote

If your application includes resources for subcultures, place each subculture in its own directory. Do not place subcultures in subdirectories of their main culture's directory.

.NET Framework 4
サテライト アセンブリの作成

トピック「リソースのパッケージ化と配置」で説明したハブ アンド スポーク モデルは、リソースを使用するアプリケーションを開発する場合に推奨されるデザインの実装です。

ハブ アンド スポーク モデルでは、リソースを簡単に見つけて使用できるように、リソースを特定の場所に配置する必要があります。 決められたとおりにリソースのコンパイルと名前付けを行わなかったり、正しい場所にリソースを配置しなかったりした場合、共通言語ランタイムはリソースを見つけることができません。 その結果、ランタイムは既定のリソース セットを使用します。 リソース名については、CultureInfo クラスまたは「リソースのパッケージ化と配置」を参照してください。

.resources ファイルをコンパイルしてサテライト アセンブリにする場合は、アセンブリ リンカー (Al.exe) を使用します。 Al.exe は、指定された .resources ファイルからアセンブリを作成します。 定義上、サテライト アセンブリにはリソースだけを含めることができます。 実行可能コードを含めることはできません。

ファイル strings.de.resources からアプリケーション MyApp 用のサテライト アセンブリを作成する Al.exe コマンドを次に示します。

al /t:lib /embed:strings.de.resources /culture:de /out:MyApp.resources.dll

ファイル strings.de.resources からアプリケーション MyApp 用のサテライト アセンブリを作成する Al.exe コマンドを次に示します。 /template オプションにより、このサテライト アセンブリは親アセンブリ MyApp.dll からアセンブリ メタデータを継承します。

al /t:lib /embed:strings.de.resources /culture:de /out:MyApp.resources.dll
/template:MyApp.dll

上記の例で使用した Al.exe のオプションを詳しく説明する表を次に示します。

オプション

説明

/t:lib

/t オプションは、サテライト アセンブリをコンパイルしてライブラリ (.dll) ファイルを作成することを指定します。 サテライト アセンブリは、コードを含むわけでも、アプリケーションのメイン アセンブリでもないため、実行不可能です。 したがって、サテライト アセンブリは DLL として保存する必要があります。

/embed:strings.de.resources

/embed オプションは、Al.exe がアセンブリをコンパイルするときに使用するソース ファイルの名前を指定します。 1 つのサテライト アセンブリの中に複数の .resources ファイルを埋め込むことができます。 ただし、ハブ アンド スポーク モデルに従う場合は、カルチャごとにサテライト アセンブリを 1 つずつコンパイルする必要があります。 しかし、文字列およびオブジェクト用として、別個の .resources ファイルを作成できます。

/culture:de

/culture オプションは、コンパイルするリソースのカルチャを指定します。 ランタイムは、指定されたカルチャ用のリソースを検索するときに、この情報を使用します。 このオプションを省略しても Al.exe はリソースをコンパイルしますが、ランタイムでは、リソースが要求されても、そのリソースを検出できなくなります。

/out:MyApp.resources.dll

/out オプションは、出力ファイルの名前を指定します。 この名前は、名前付け標準 baseName.resources.extension に従う必要があります。baseName はメイン アセンブリの名前で、extension は有効な拡張子 (たとえば .dll) です。 ランタイムは、出力ファイル名からサテライト アセンブリのカルチャを判断することはできません。 したがって、上記の /culture オプションによってカルチャを指定することが重要です。

/template:filename

/template オプションは、カルチャ フィールドを除くすべてのアセンブリ メタデータを継承する元となるアセンブリを指定します。 サテライト アセンブリの継承元とするアセンブリは、厳密な名前を持つことが必要です。

有効な Al.exe のオプションの一覧については、「アセンブリ リンカー (Al.exe)」を参照してください。

グローバル アセンブリ キャッシュ内にサテライト アセンブリをインストールする場合、アセンブリは厳密な名前を持っている必要があります。 厳密な名前を持つアセンブリには、有効な公開/秘密キーのペアによる署名が付いています。 厳密な名前の詳細については、「厳密な名前付きアセンブリ」を参照してください。

通常、アプリケーションの開発中に、最終的な公開/秘密キーのペアにアクセスすることはありません。 サテライト アセンブリをグローバル アセンブリ キャッシュ内にインストールし、そのアセンブリが確実に予測どおりに機能するようにするために、遅延署名と呼ばれる技術を使用できます。 アセンブリへの署名を遅延させる場合は、厳密な名前による署名用のスペースをビルド時にファイル内に予約しておいてください。 実際の署名は、最終的な公開/秘密キーのペアが利用可能になるまで遅延されます。

公開キーの取得

アセンブリへの署名を遅延するには、公開キーにアクセスする必要があります。 実際の公開キーを取得するには、最終的な署名を行う社内の組織から取得するか、厳密名ツール (Sn.exe) を使用して公開キーを作成します。

テスト用の公開キーと秘密キーのペアを作成し、ファイル TestKeyPair.snk に保存する Sn.exe コマンドを次に示します。 –k オプションは、Sn.exe で新しいキー ペアを作成し、指定のファイルに保存することを指定します。

sn –k TestKeyPair.snk 

テスト用のキー ペアを含むファイルから公開キーを抽出できます。 TestKeyPair.snk から公開キーを抽出し、PublicKey.snk に保存するコマンドを次に示します。

sn –p TestKeyPair.snk PublicKey.snk

アセンブリへの遅延署名

公開キーを取得または作成したら、アセンブリ リンカー (Al.exe) を使用してアセンブリをコンパイルし、署名を遅延することを指定します。

アプリケーション MyApp 用の厳密な名前付きサテライト アセンブリを strings.ja.resources ファイルから作成する Al.exe コマンドを次に示します。

al /t:lib /embed:strings.ja.resources /culture:ja /out:MyApp.resources.dll /delay+ /keyfile:PublicKey.snk

/delay+ オプションは、アセンブリへの署名を遅延することを指定します。 /keyfile: オプションは、アセンブリへの署名を遅延するために使用する公開キーを含むキー ファイルの名前を指定します。

遅延署名の詳細については、「アセンブリへの遅延署名」を参照してください。

厳密な名前を持つアセンブリは、バインディング要件を満たすアセンブリを判断するためにランタイムが使用するバージョン情報を持っています。 このトピックの詳細については、「アセンブリのバージョン管理」を参照してください。」

アセンブリへの再署名

後日、遅延署名されたサテライト アセンブリに対して、実際のキー ペアで再署名する必要があります。 その作業は、Sn.exe を使用して実行できます。

MyApp.resources.dll に対して、ファイル RealKeyPair.snk に格納されている実際のキー ペアで署名する Sn.exe コマンドを次に示します。 –R オプションは、以前に署名されたアセンブリ、または遅延署名されたアセンブリを Sn.exe で再署名することを指定します。

sn –R MyApp.resources.dll RealKeyPair.snk 

グローバル アセンブリ キャッシュへのサテライト アセンブリのインストール

リソース フォールバック プロセスでランタイムが最初にリソースを検索する場所はグローバル アセンブリ キャッシュです。 詳細については、「リソースのパッケージ化と配置」の「リソース フォールバック プロセス」を参照してください。 したがって、リソースをグローバル アセンブリ キャッシュにインストールする方法を知っておく必要があります。 厳密な名前を付けてコンパイルしたサテライト アセンブリは、そのままグローバル アセンブリ キャッシュにインストールできます。 グローバル アセンブリ キャッシュ ツール (Gacutil.exe) を使用すると、アセンブリをキャッシュ内にインストールできます。

MyApp.resources.dll をグローバル アセンブリ キャッシュにインストールする Gacutil.exe のコマンドを次に示します。

gacutil /i:MyApp.resources.dll

/i オプションは、指定したアセンブリをグローバル アセンブリ キャッシュにインストールすることを指定します。 このコマンドの実行結果として、キャッシュ内にエントリが配置されます。これにより、この .resources ファイル内のエントリにアクセスできるようになります。 指定したリソースをキャッシュ内にインストールすると、そのリソースを使用するようにデザインされたすべてのアプリケーションで、そのリソースを利用できるようになります。

サテライト アセンブリをコンパイルすると、それらのすべてに同じ名前が付けられます。 ランタイムは、コンパイル時に Al.exe の /culture オプションで指定されたカルチャと、各アセンブリのディレクトリの位置に従って各サテライト アセンブリを区別します。 そのため、サテライト アセンブリは、決められたディレクトリ位置に配置する必要があります。

グローバル アセンブリ キャッシュ内にインストールしないアプリケーションについて、サンプルのディレクトリ構造と位置に関する要件を次の図に示します。 ファイル拡張子 .txt および .resources が付いたファイルは、最終的なアプリケーションには付属していません。 それらは、最終的なサテライト リソース アセンブリを作成するまでの中間リソース ファイルです。 この例では、.txt ファイルを .resx ファイルに置き換えることもできます。 .resx ファイルは、唯一オブジェクトを含めることのできる種類の中間リソースです。

サテライト アセンブリ ディレクトリ

サテライト アセンブリ
メモメモ

アプリケーションにサブカルチャ用のリソースを含める場合は、各サブカルチャを専用のディレクトリ内に配置します。 サブカルチャをそのメイン カルチャのディレクトリのサブディレクトリ内には配置しないでください。

コミュニティ コンテンツ   コミュニティ コンテンツとは
新しいコンテンツの追加 RSS  注釈
Processing
© 2012 Microsoft. All rights reserved. 使用条件 | 商標 | プライバシー
Page view tracker