I'm trying to utilize a Shared Project concept to share the client application logic between WPF project and Android (Xamarin.Forms). In both projects I want to use the same localizable texts, therefore, it looks logical for me to move resource file (with texts) to the shared project.
The following sample is from WPF project, but the faced problem is related to shared projects, not WPF.
In my WPF project in XAML based views I access the string values as follows:
<TextBlock Text="{x:Static i18n:Strings.WelcomeMessage}" />
The file Strings.resx and its translation are located in the folder I18N, ie. they are not placed in the project's root. Therefore the generated public class Strings is placed to the namespace TestApp.I18N. When the I18N folder belongs to WPF project directly, everything works great, but if I move I18N to the shared project, the WPF application crashes with the exception:
Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "TestApp.I18N.Strings.resources" was correctly embedded or linked into assembly WPF at compile time, or that all the satellite assemblies required are loadable and fully signed.
If I look into compiled assembly using some disassembly tool I can see the difference between both compilations:
- In the compilation where I18N folder belongs to the shared project I see the resource named
TestApp.Strings.resources - In the compilation where I18N folder belongs to the WPF project I see the resource named
TestApp.I18N.Strings.resources
It actually explains good why in the first case the app crashes. And it is clear what workaround can be used (I can put Strings.resx and related to the project root). But I can feeling that having resources in shared project isn't good idea, because lack of proper support. Can someone share own experience in that direction? Why resource files from shared project are interpreted a bit differently by the compiler?
