問題タブ [satellite-assembly]

私はhttp://www.codeproject.com/Articles/30035/Simple-WPF-Localizationプロジェクトを使用してアプリをローカライズしています。これは (まあ) シンプルでわかりやすく、動的な言語変更をサポートしているためです。

すべての言語リソースをメイン プロジェクト (resources.resx、resources.ja-JP.resx) に配置しました。こうすることで、サテライト アセンブリが自動的に生成され、正しいフォルダー構造に配置されます。

ただし、すべての言語リソース (デフォルト/ニュートラルのもの - resources.resx を除く) を別のプロジェクトに入れたいと思います。これにより、翻訳の 1 つだけを変更する必要がある場合は、メイン プロジェクト (アプリケーション ソースを含む) を再構築する必要はありません。

したがって、言語リソースのみを含む VS プロジェクトを作成する標準的な方法 (または少なくとも非常に簡単な方法) があるかどうかを知りたいです。

私はすでに空のプロジェクトを作成し、出力をクラスライブラリに設定し、アセンブリを実行可能ファイルの名前と一致させようとしました。正しいサテライト アセンブリが正しいフォルダーに作成されますが、dll も生成されます。完全に言語リソースのみのc#またはwpfのプロジェクトタイプがあれば、それは本当に簡単ですが、それについての参照が見つからないようです。

（ところで、私はWPFプロジェクトでVS 2010を使用しています）

助けてくれてありがとう！

生成されたすべてのサテライト アセンブリを自動的に含めるように WiX を設定できますか?

目標は、最大 10 の言語で使用できるローカライズされた文字列を含むアプリケーションをインストールする単一の英語 MSI を用意することです。

私はこの既存のSO質問を見つけました:

WiX でビルドされた MSI にサテライト アセンブリ (ローカライズされたリソース) を含めるにはどうすればよいですか?

ただし、その解決策は、カルチャ バリアントごとに新しいコンポーネントとディレクトリの定義を手動で追加する必要があることを示唆しています。

それが唯一の方法ですか、それとも WiX が Visual Studio プロジェクト定義から各言語について何らかの方法で自動的に学習できるのでしょうか?

(VS2010 と WiX 3.8 を実行)

サテライト アセンブリは、ディスク上の適切な名前のサブフォルダーに存在する必要があります。たとえば、AppDomain.AssemblyResolve イベントを介してメモリからロードできますか?

アセンブリをメモリからロードできることは知っていますが、.Net は、サテライト アセンブリを探すときに AssemblyResolve イベントを使用します。

私は、さまざまなサイズの複数のアプリケーションと数十 (場合によっては数百) のアセンブリで構成される .Net ソフトウェア製品に取り組んでいます。すべてを複数の言語に翻訳する必要があります。

どこを見ても、.NET で文字列をローカライズする方法として提案されているのは、リソース文字列を使用してサテライト アセンブリを作成することです。もちろん、これらの例はすべて 1 つのアセンブリと、ローカリゼーションを技術的に機能させる方法を示しているだけです。私の問題は、実際には、これがアセンブリの大規模なセットにどのように拡張されるかがわからないことです。

各アセンブリのアプローチを単純に複製すると、非常に多数のサテライト アセンブリを維持および展開することになり、それを必要とするすべてのアセンブリで 1 つの同じ文字列/翻訳を追跡する必要があります。翻訳が変更されるたびに、すべてのアセンブリでこの文字列の使用箇所をすべて見つけて変更する必要があります。

翻訳を更新する必要があるたびに、多数のリソース ファイルからすべてを抽出して翻訳者に送信し、その結果を適切なリソースに再度配布する必要があります。これはもちろん実行できます。スクリプト化できる (そしてスクリプト化する必要がある) ものもあると思います。ただし、特にスムーズで効率的だとは思いません。

私が考えることができる 1 つの代替手段は、ローカライズされた文字列の中央リポジトリとして機能する専用の翻訳アセンブリ (サテライト アセンブリを含む) を作成することです。すべてのアセンブリのすべての文字列のすべての翻訳がそこに移動し、翻訳を吐き出すために、すべてのアセンブリによって順番に参照されます。

これにより、メンテナンスがはるかに簡単になるように見えますが、もちろん、リソース文字列の膨大なセットを備えたこの中央アセンブリは、実際にはそれらのほんの一部しか必要としない最小のアプリケーションと一緒にデプロイする必要があります。さらに、このアセンブリは多くの開発者によって頻繁に変更される必要があり、競合のリスクが高くなります。

私の質問は次のとおりです。
サテライト アセンブリを介したローカリゼーションのアプローチは、多くのアセンブリを含む大規模なソフトウェア プロジェクトにどのように対応できるのでしょうか? 推奨される戦略とベスト プラクティスは何ですか?

いくつかのファイルを埋め込むプロジェクトがあり、そのうちの 2 つは.SMS.something. プロジェクトがコンパイルされると、"SMS" カルチャのサテライト アセンブリが生成されますが、サテライト アセンブリを使用する場所をどこにも指定していません。それはカルチャですか?

説明を求めてあちこち検索しましたが、途方に暮れています。私が見つけたのは、実際のカルチャのリソース アセンブリを実行可能ファイルに埋め込もうとしている人々だけでしたが、これは私の場合ではありません。私は、1 つの言語のみであるすべての埋め込みリソースを同じアセンブリに入れたいだけです。

このサテライト アセンブリの自動生成を防止したり、SMS がカルチャではないことを指定したりするにはどうすればよいですか?

ローカリゼーションをサポートしたい 1 つのアプリケーションに取り組んでいます。ローカリゼーションを実装するためにサテライト アセンブリの概念を実装しましたが、問題は、選択した言語に基づいて実行時にすべてのコントロールのテキストをロード/レンダリングするため、アプリケーションのロードが非常に遅くなることです。

今私の質問は次のとおりです。ロード時間中に遅延/ちらつきなしにすべてのメインフォームコントロールを更新できるより良いアプローチはありますか?

c#.net Winforms を使用してアプリケーションを開発しています。

私のプロジェクトの構造:

これが私が試したものです[サンプルコード]：

注 : このサンプル アプリケーションには非常に少数のコントロールしか含まれていませんが、実際のアプリケーションにはロード中に遅延/ちらつきが発生するコントロールが多すぎるため、これは正常に機能します。

以下のプログラムは、サテライト リソース ファイルからリソース文字列を取得することになっています。VS2015 を使用して target framework='NET Framework 4.5.2' でコンパイルすると正常に動作します。ただし、target framework='NET Framework 3.5' を設定すると、サテライト リソース ファイルを見つけることができなくなり、既定のリソースにフォールバックします。

.exe ファイルとサテライト .dll ファイルを調べたところ、それらが異なる .net バージョンにコンパイルされていることがわかりました (それらを生成したのは同じコンパイルでしたが)。

サテライト dll が間違った .Net バージョンを取得しているようです。誰かがこれを経験しましたか?解決策はありますか? (プロジェクトを最新の .Net バージョンにアップグレードする以外)

編集: 開発環境の更新がうまくいかなかったようです。コンピューター全体の再インストールは役に立ちましたが、単に .Net と Visual Studio を再インストールするだけでは役に立ちません! （単純な再インストールではリセットされないものがレジストリデータベースにあるのだろうか）

必要なカルチャのアセンブリを見つけるのに役立つコード行を次に示します。

しかし、アプリケーション用にサテライト アセンブリが存在する言語を見つける方法として、3 つの異なるフォルダーが作成された 3 つの言語サポートがある場合、これらのフォルダーと言語をサポートする必要があります。ユーザーが言語を選択できるドロップダウンでこれを使用し、サポートされているサテライト アセンブリに従ってドロップダウン値を動的にロードする必要があります。

自分の言語を Web アクセス UI に使用するために、自分のカルチャを Team Foundation Server Web アプリケーションに追加するにはどうすればよいですか? (プロファイル ロケール設定の [言語] コンボボックスに自分の言語を追加します。)

"C:\Program Files\Microsoft Team Foundation Server 14.0\Application Tier\Web Services\bin\de" フォルダーの下のリソース ファイルを Hex エディターで変更してドイツ語を変更しようとしましたが、新しい dll が機能しません。
また、Visual Studio で新しいリソース dll を作成し、同じリソース名と異なる値、同じファイル バージョンと .net バージョンを使用します。しかし、リソース dll (例: Microsoft.TeamFoundation.Server.WebAccess.Welcome.resources.dll) を置き換えると、UI は既定の言語を読み込み、新しい dll を無視します。
下の図に示すように、選択した言語 (ドイツ語) が表示されておらず、デフォルトの言語 (英語) が表示されていても、新しい翻訳テキストは表示されません。
私は何が欠けていますか？