共有プロジェクトの概念を利用して、WPF プロジェクトと Android (Xamarin.Forms) の間でクライアント アプリケーション ロジックを共有しようとしています。両方のプロジェクトで同じローカライズ可能なテキストを使用したいので、(テキストを含む) リソース ファイルを共有プロジェクトに移動するのが理にかなっています。
次のサンプルは WPF プロジェクトのものですが、直面している問題は WPF ではなく共有プロジェクトに関連しています。
XAML ベースのビューの WPF プロジェクトでは、次のように文字列値にアクセスします。
<TextBlock Text="{x:Static i18n:Strings.WelcomeMessage}" />
ファイルStrings.resxとその翻訳はフォルダにありますI18N。プロジェクトのルートには配置されません。したがって、生成さpublic class Stringsれた は namespace に配置されますTestApp.I18N。I18N フォルダーが WPF プロジェクトに直接属している場合、すべてがうまく機能しますが、I18N を共有プロジェクトに移動すると、WPF アプリケーションが例外でクラッシュします。
指定されたカルチャまたはニュートラル カルチャに適したリソースが見つかりませんでした。コンパイル時に "TestApp.I18N.Strings.resources" がアセンブリ WPF に正しく埋め込まれているかリンクされていること、または必要なすべてのサテライト アセンブリが読み込み可能で完全に署名されていることを確認してください。
逆アセンブリ ツールを使用してコンパイルされたアセンブリを調べると、両方のコンパイルの違いがわかります。
- I18N フォルダーが共有プロジェクトに属しているコンパイルでは、次の名前のリソースが表示されます
TestApp.Strings.resources - I18N フォルダーが WPF プロジェクトに属しているコンパイルでは、次の名前のリソースが表示されます
TestApp.I18N.Strings.resources
最初のケースでアプリがクラッシュする理由を実際に説明しています。そして、どのような回避策を使用できるかは明らかです (Strings.resxプロジェクトのルートに配置して関連付けることができます)。しかし、適切なサポートが不足しているため、共有プロジェクトにリソースを配置することはお勧めできません。誰かがその方向で自分の経験を共有できますか? コンパイラによる共有プロジェクトのリソース ファイルの解釈が少し異なるのはなぜですか?