ランタイム生成アセンブリのグローバル化

Question

背景

プロジェクトは、UserControlを定義するためのすべての要素を含むいくつかのファイル（ユーザーソース、デザイナーコードのCodeCompileUnit、およびresxファイル）をインストールします。実行時に、これらのファイルはアセンブリにコンパイルされ、クラスはメインアプリケーションによって消費されます（アセンブリは必要な場合にのみ更新されます）。

質問

プロジェクトはグローバル化する必要があり、そのプロセスの一部として、これらのファイルのローカライズを提供する必要があります。 2つのオプションは、メインアセンブリのサテライトアセンブリにコンパイルできる異なるロケール（同じファイル内または追加のサイドバイサイドファイル）に追加のresxファイルを含めることを許可するか、またはサポートされている各言語の各完全ファイル。サポートされている言語に適したセットをコンパイルします。

• 検討する価値のある他のオプションはありますか？
• 提案した解決策のいずれかに固有の問題は何ですか？

---

制約/免責事項
シナリオは理想的とは言えず、一部の領域（最初からグローバル化するなど）でより良い選択を行うこともできましたが、プロジェクトのこの時点では変更できません。あなたが提供できるアドバイス、解決策、またはリードに感謝します。ありがとう。

Answer 1

カルチャごとに個別のサテライトアセンブリを作成します。これには2つの利点があります：

• すべてのアセンブリを一度に構築し、カルチャに応じてまたではなく、バージョン番号とファイル名の組み合わせごとに明確なファイルを作成できます。
• 同じインストールで複数のアセンブリを使用し、使用する言語をシステム言語やユーザー設定などに基づいて設定できます。これにより、再構築とコピーを続ける必要がないため、開発とテストが大幅に簡単になります。言語を変更するためだけにファイルを使用します。
• .NET i18nの動作方法です。私は.NET i18nの専門家ではありませんが（「Guy Smith-Ferrierの本を読む」をお勧めします！）、通常、フレームワークは期待どおりのモデルに従うと最適に機能することがわかります。

「サテライトアセンブリの構築」の最後の部分であっても、実行時に行われます（代わりにインストール時に行うことができますか？）少なくとも2番目と3番目の利点があります。また、サテライトアセンブリを（ユーザーのボックスに構築するのではなく）提供するというより通常のルートに実行する場合、変更する必要はほとんどありません。

質問を誤解してしまった場合はおpびします...

Answer 2

展開後に追加の言語を追加する予定がない場合（少なくともソフトウェアの更新がない場合は）、追加するすべてのRESXファイルをサテライトアセンブリにコンパイルしてください。そうすれば、デプロイされたユーザーは編集できません。