1

バックグラウンド

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

質問

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

  • 他に検討する価値のあるオプションはありますか?
  • 私が提案したソリューションのいずれかに固有の問題は何ですか?

制約/免責事項
シナリオが理想的とは言えず、一部の領域 (最初からのグローバル化など) でより良い選択を行うことができた可能性があることは認識していますが、プロジェクトのこの時点ではそれらを変更することはできません。アドバイス、解決策、または手がかりを提供していただければ幸いです。ありがとう。

4

2 に答える 2

3

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

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

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

質問の意味が間違っていたらすみません…

于 2009-02-02T14:49:22.827 に答える
2

If you're not planning on adding additional languages after deployment (at least not without a software update), then I'd favor compiling all the additional RESX files into a satellite assembly that you include. That way, they're not user editable once they're deployed.

于 2009-01-15T05:15:01.133 に答える