[Bug] ResourceManager.GetString always returning values for the default culture

marcellangmaier commented 4 years ago

Description

When having a Resource file (Resource1.resx) with default settings (ResXFileCodeGenerator, Embedded Resource) in my project with one translation (Resource1.en.resx) the ResourceManager is always returning the value from Resource1.resx even if queried with CultureInfo("en") Parameter.

Testing the same thing in a Windows Forms application works as expected.

Steps to Reproduce

Create default Shell Application
Add Toolbar Item to ItemsPage.xaml with Clicked Handler
Add resource file "Resource1.resx" to Common Project, Create Key "Key1" with value "Value1 neutral"
Add resource file "Resource1.en.resx" to Common Project. Create Key "Key1" with value "Value1 english"

Add the following code in Clicked Handler:

    var en = System.Globalization.CultureInfo.GetCultureInfo("en");

    var s = Resource1.ResourceManager.GetString("Key1");
    await DisplayAlert("Value (no culture)", s, "OK");

    s = Resource1.ResourceManager.GetString("Key1", en);
    await DisplayAlert("Value (en)", s, "OK");

Expected Behavior

Culture of my device: de First alert box should show the value: "Value1 neutral" Second alert box should show the value: "Value1 english"

Actual Behavior

Both boxes are showing the neutral value

Basic Information

Version with issue:
Last known good version:
IDE: Version 16.6.0 Preview 5.0
Platform Target Frameworks: Android: 9.0
Affected Devices: Samsung Galaxy S9, Adnroid Emulator

Sample Project resxtest.zip

VS bug #1130016

StephaneDelcroix commented 4 years ago

this is outside of the scope of Xamarin.Forms. transferring to Android

thierryiseli commented 4 years ago

I have the same issue. With iOS it works without problems.

thierryiseli commented 4 years ago

I do not know exactly what the mistake was, but now it basically works. The only thing I did was to remove the assembly specification in XAML and update Xamarin.Forms to the latest version.

xmlns:resources="clr-namespace:MyApp.Localization;assembly=MyApp" to xmlns:resources="clr-namespace:MyApp.Localization"

Furthermore I have moved all resx-files into an own namespace.

DevEddy commented 4 years ago

Same problem here for Android... this was released. Any solution?

Edit: @thierryiseli could you describe in more detail what you did to solve this problem?

brendanzagaeski commented 4 years ago

Workaround

Use a text editor to open the .csproj file for the affected app project, and replace the end of the file with the following lines:

  <Target Name="_ResolveSatellitePaths"
    DependsOnTargets="_ResolveAssemblies">
    <ResolveAssemblyReference
        AllowedAssemblyExtensions="$(AllowedReferenceAssemblyFileExtensions)"
        AssemblyFiles="@(ResolvedUserAssemblies)"
        AutoUnify="$(AutoUnifyAssemblyReferences)"
        FindDependencies="True"
        FindRelatedFiles="False"
        FindSatellites="True"
        SearchPaths="$(AssemblySearchPaths)"
        TargetFrameworkMoniker="$(TargetFrameworkMoniker)"
        TargetFrameworkMonikerDisplayName="$(TargetFrameworkMonikerDisplayName)"
        TargetFrameworkDirectories="$(TargetFrameworkDirectory)">
      <Output TaskParameter="SatelliteFiles" ItemName="_AndroidResolvedSatellitePaths"/>
    </ResolveAssemblyReference>
  </Target>
</Project>

Explanation: This reverts the _ResolveSatellitePaths MSBuild target to the previous implementation as used in Xamarin.Android 10.2.

Preliminary investigation notes for the Xamarin team

Alternative test case

The following sample produces the issue as well: https://docs.microsoft.com/xamarin/xamarin-forms/app-fundamentals/localization/text

(To see the issue on a Google Pixel 3, navigate to System > Languages & Input in the system Settings and select a language like German or French as the primary language.)

Investigation notes

This is not an issue with libmonosgen-2.0.so or mscorlib.dll. It is instead an issue with the MSBuild targets that was introduced by: https://github.com/xamarin/xamarin-android/commit/65a917a91ac01c632e6526fbfe823826613f3171

One clue about how the new approach is failing and why the test suite didn't catch it is that it seems the issue only happens when packaging and deploying from within Visual Studio. Packaging and deploying from the command line via msbuild -restore -t:Install seems to avoid the issue.

Example output from _ResolveSatellitePaths for a command line deployment:

Target "_ResolveSatellitePaths: (TargetId:242)" in file "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets" from project "C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization.Android\UsingResxLocalization.Android.csproj" (target "_PrepareAssemblies" depends on it):
Added Item(s): 
    _AndroidResolvedSatellitePaths=
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\de\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\de-CH\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\es\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\fr\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\id\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\ja\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\ms\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\pt\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\pt-BR\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\zh-Hans\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\zh-Hant\UsingResxLocalization.resources.dll
Done building target "_ResolveSatellitePaths" in project "UsingResxLocalization.Android.csproj".: (TargetId:242)

Example output from _ResolveSatellitePaths for a Visual Studio deployment:

Target "_ResolveSatellitePaths: (TargetId:72)" in file "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets" from project "C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization.Android\UsingResxLocalization.Android.csproj" (target "_PrepareBuildApk" depends on it):
Done building target "_ResolveSatellitePaths" in project "UsingResxLocalization.Android.csproj".: (TargetId:72)

brendanzagaeski commented 4 years ago

Cross-referencing note for the Xamarin team

Corresponding Developer Community item: https://developercommunity.visualstudio.com/content/problem/1030901/localization-in-android-doesnt-work-4.html

marcellangmaier commented 4 years ago

I can confirm that adding the target to the android project csproj file fixes the problem.

codeinstinct commented 4 years ago

I've tried the workaround given by @brendanzagaeski, but it doesn't resolve the problem for me.

I'm working on the sample from here

Steps to reproduce: 1) Insert workaround in Android project, towards the end of the .csproj as suggested. 2) Change line in AssemblyInfo.cs in forms project to [assembly: NeutralResourcesLanguage("de")] 3) Clean solution & Rebuild

Observations:

Language is still the same (default, english) in the android app
UWP works correctly though

brendanzagaeski commented 4 years ago

@codeinstinct, thanks for the info!

I looked into that a little, and in short, it appears to be an unrelated complication that also affects earlier versions such as Visual Studio 2019 version 16.5. To resolve it, change the line to:

[assembly: NeutralResourcesLanguage("de", UltimateResourceFallbackLocation.Satellite)]

I've submitted an issue against the sample about updating that: https://github.com/xamarin/xamarin-forms-samples/issues/626.

codeinstinct commented 4 years ago

Thanks @brendanzagaeski, this worked!

MobilyteApps commented 4 years ago

@DevEddy:- Hi Have you find any solution ?

DevEddy commented 4 years ago

Workaround

Use a text editor to open the .csproj file for the affected app project, and replace the end of the file with the following lines:

  <Target Name="_ResolveSatellitePaths"
    DependsOnTargets="_ResolveAssemblies">
    <ResolveAssemblyReference
        AllowedAssemblyExtensions="$(AllowedReferenceAssemblyFileExtensions)"
        AssemblyFiles="@(ResolvedUserAssemblies)"
        AutoUnify="$(AutoUnifyAssemblyReferences)"
        FindDependencies="True"
        FindRelatedFiles="False"
        FindSatellites="True"
        SearchPaths="$(AssemblySearchPaths)"
        TargetFrameworkMoniker="$(TargetFrameworkMoniker)"
        TargetFrameworkMonikerDisplayName="$(TargetFrameworkMonikerDisplayName)"
        TargetFrameworkDirectories="$(TargetFrameworkDirectory)">
      <Output TaskParameter="SatelliteFiles" ItemName="_AndroidResolvedSatellitePaths"/>
    </ResolveAssemblyReference>
  </Target>
</Project>

Explanation: This reverts the _ResolveSatellitePaths MSBuild target to the previous implementation as used in Xamarin.Android 10.2.

Preliminary investigation notes for the Xamarin team

Alternative test case

The following sample produces the issue as well: https://docs.microsoft.com/xamarin/xamarin-forms/app-fundamentals/localization/text

(To see the issue on a Google Pixel 3, navigate to System > Languages & Input in the system Settings and select a language like German or French as the primary language.)

Investigation notes

This is not an issue with libmonosgen-2.0.so or mscorlib.dll. It is instead an issue with the MSBuild targets that was introduced by: https://github.com/xamarin/xamarin-android/commit/65a917a91ac01c632e6526fbfe823826613f3171

One clue about how the new approach is failing and why the test suite didn't catch it is that it seems the issue only happens when packaging and deploying from within Visual Studio. Packaging and deploying from the command line via msbuild -restore -t:Install seems to avoid the issue.

Example output from _ResolveSatellitePaths for a command line deployment:

Target "_ResolveSatellitePaths: (TargetId:242)" in file "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets" from project "C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization.Android\UsingResxLocalization.Android.csproj" (target "_PrepareAssemblies" depends on it):
Added Item(s): 
    _AndroidResolvedSatellitePaths=
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\de\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\de-CH\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\es\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\fr\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\id\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\ja\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\ms\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\pt\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\pt-BR\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\zh-Hans\UsingResxLocalization.resources.dll
        C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization\bin\Debug\netstandard2.0\zh-Hant\UsingResxLocalization.resources.dll
Done building target "_ResolveSatellitePaths" in project "UsingResxLocalization.Android.csproj".: (TargetId:242)

Example output from _ResolveSatellitePaths for a Visual Studio deployment:

Target "_ResolveSatellitePaths: (TargetId:72)" in file "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets" from project "C:\Temp\LocalizationDemo\UsingResxLocalization\UsingResxLocalization.Android\UsingResxLocalization.Android.csproj" (target "_PrepareBuildApk" depends on it):
Done building target "_ResolveSatellitePaths" in project "UsingResxLocalization.Android.csproj".: (TargetId:72)

@MobilyteApps yeah, this workaround works for me

-- Eddy

MobilyteApps commented 4 years ago

@DevEddy:- Hey, I think this solution is for visual studio for MAC, But i am facing issue in Visual studio 16.6 version and Android 10, did you find problem ?

brendanzagaeski commented 4 years ago

@MobilyteApps, that workaround is indeed relevant on Windows. That's where I confirmed the issue and prepared the workaround.

If the workaround does not have an effect for your project, then there is a chance some other complication might be involved for your project. In that case, if you might be able to submit a new issue that has the diagnostic MSBuild output from your project zipped and attached so the team can take a look, that would be perfect. Thanks in advance!

MobilyteApps commented 4 years ago

@brendanzagaeski :- Please find attached code.

MobilyteApps commented 4 years ago

@brendanzagaeski :- Please find attached code. Resources.zip

MobilyteApps commented 4 years ago

@brendanzagaeski :- I am using Xamrin froms Latest and Visual studio for Windows 16.6

The language selected code is // item.code will be

new Item { Title = "Española".ToString(), Code = "es-pr", IsSelected=true }, new Item { Title = "English".ToString(), Code = "en-gb", IsSelected=false }

CrossMultilingual.Current.CurrentCultureInfo = new System.Globalization.CultureInfo(item.Code); AppResources.Culture = CrossMultilingual.Current.CurrentCultureInfo;

and Resources file will be Resources.zip

Note:- Few days back when i was VS 16.3.2 that Worked but when i updated to new VS 16.6 then problem comes in Android 10/9

Can you suggest if any thing missed in new updates?

Thanks

brendanzagaeski commented 4 years ago

@MobilyteApps, thanks for the info. Just to make sure, have you already applied the workaround to the Xamarin.Android app project? I forgot to double-check on that before. Adding the workaround to the the Xamarin.Forms .NET Standard won't change the behavior, so it needs to go in the Android app project part of the solution.

As one other test, I tried copying the example resource files from that Resources.zip file into the localization sample, modified the sample to use them, and applied the workaround to the Android App project. When I ran the app on device with the preferred language set to Spanish, the localizations from the .es.resx file were shown.

AdjustedSample.zip

Does this adjusted sample behave as expected in your environment too?

MobilyteApps commented 4 years ago

@brendanzagaeski:- Hey, Thanks for responing. Yes i already followed same structure and by default i am getting Spanish, because my project requirement but when i convert to English, then it can not converted into English, it remains showing Spanish.

MobilyteApps commented 4 years ago

@brendanzagaeski:-

Just to make sure, have you already applied the workaround to the Xamarin.Android app project?

Yes

Does this adjusted sample behave as expected in your environment too? --> Yes

Please see attachment:- New folder.zip

By Default my form is showing Spanish as my requirement and when i click to change in English then calls below method and my item.code will be English but my form is not converted into English.

CrossMultilingual.Current.CurrentCultureInfo = new System.Globalization.CultureInfo(item.Code);

Note- For VS 16.3.2 there were no problem but when i updated in to 16.6 VS for Window its giving problem,

Thanks

brendanzagaeski commented 4 years ago

@MobilyteApps, interesting. I'm not sure what would be happening there. If you get a chance to create a new issue and provide the zipped up diagnostic MSBuild output from your project or a zipped up sample project that demonstrates the problem, the team can take a look. Thanks!

EmilAlipiev commented 4 years ago

Does Appcenter and Azure Pipelines always use the latest version of VS2019? why i have this problem also when I built it using Azure Pipelines with windows-2019 selected? Because you claim that it doesnt occur using command line.I thought Azure Pipelines uses comman line for builds not?

Beside that is that workaround temporarily until actual solution is applied or we can keep it?

brendanzagaeski commented 4 years ago

@EmilAlipiev, thanks for the question! It sounds like something else might be happening for the Azure Pipelines and App Center builds. Those environments have not yet been updated to Visual Studio 2019 version 16.6 with Xamarin.Android SDK version 10.3 (d16-6) (additional details below), so they would not yet be affected by this issue. If you might be able to collect a diagnostic MSBuild log from your project for the problematic Azure Pipelines or App Center build and attach on a new GitHub issue (or a new Developer Community feedback item via Help > Send Feedback > Report a Problem if it contains private information) so the team can take a look, that would be perfect. Thanks in advance!

Beside that is that workaround temporarily until actual solution is applied or we can keep it?

The temporary workaround will be OK to leave in place after the fix is published. The downside will be a small extra time cost during the build and deploy process (on the order of 200 milliseconds). If desired, the improved approach from the upcoming fix can also be applied as a workaround (to avoid the extra 200 milliseconds). To do that, replace the bottom of the Android app project with the following lines instead of the workaround posted above:

  <PropertyGroup>
    <SignAndroidPackageDependsOn Condition=" '$(BuildingInsideVisualStudio)' == 'True' ">
      BuildOnlySettings;
      $(SignAndroidPackageDependsOn);
    </SignAndroidPackageDependsOn>
  </PropertyGroup>
</Project>

This workaround is also OK to keep after the fix is published, but it would be recommended to remove either workaround before updating to the next generally available version (that is, when Visual Studio 2019 version 16.7 moves from Preview to Release) to ensure compatibility with future changes to the Xamarin.Android MSBuild targets.

Azure Pipelines version info

The windows-2019 hosted agents should currently be using Visual Studio 2019 version 16.5: https://docs.microsoft.com/azure/devops/pipelines/agents/hosted.

I did a quick check with a windows-2019 hosted agent and a PowerShell task to make sure that information was up-to-date:

- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: 'Get-Content "C:\Program Files (x86)\Microsoft Visual Studio\2019\*\MSBuild\Xamarin\Android\Version.commit"'

That test returned the expected Visual Studio 2019 version 16.5 version of Xamarin.Android 10.2 (d16-5):

xamarin-android/d16-5/988c811

App Center version info

On App Center, the latest version available is likewise Xamarin.Android 10.2 (d16-5):

MobilyteApps commented 4 years ago

@brendanzagaeski :- This is not the issue of the code and plugin, this issue is for visual studio windows version 16.6, i downgrade version from 16.6 to 16.3.2 and my code works. This is so much frustrating.

Thanks for support,

EmilAlipiev commented 4 years ago

So 16.5 and 16.4 has the problem also do you mean?

EmilAlipiev commented 4 years ago

Actually this bug is also on debug mode. nothing to do with release or packing. my app even debug mode always showing english if you delete the app and its data and make fresh debugging. I couldnt release before because when there is an installed version with another language, it is not overwriting but fresh install is always english (or default language). @brendanzagaeski's workaround solves problem in debug mode also for me.

MobilyteApps commented 4 years ago

So 16.5 and 16.4 has the problem also do you mean?

yes

EmilAlipiev commented 4 years ago

I have recognized something. i dont know if it is coincidence but using this workaround, after updating my app on my phone, app data has been reset as if a new installation. Anyone else seeing such behavior?

EmilAlipiev commented 4 years ago

I have recognized something. i dont know if it is coincidence but using this workaround, after updating my app on my phone, app data has been reset as if a new installation. Anyone else seeing such behavior?

This is surely happening and i have tested again and again. it has something to do with the workaround. if i dont use workaround above, app data is preserved between debug sessions but when using it, everytime app loads from the scratch. I am worried if this is the case for release as well, once you publish a new version and all users data is wiped as if they are new users. can you imagine your lose?

brendanzagaeski commented 4 years ago

@EmilAlipiev, thanks for the info! I'll plan to take a look at that scenario this weekend to see if I can reproduce it and provide some information about what's happening. There's a chance the workaround is resetting something so that the Debug configuration deployment ends up doing an adb uninstall rather than an adb uninstall -k on repeated deployments.

To make sure I look at the right scenario, if by chance you catch this message, do the following steps sound roughly accurate?

Add the workaround to the app project.
Deploy and start debugging the project in the Debug configuration with fast deployment enabled.
Save some data to the app data directory from within the running app.
Make a change to an Android resource, the AndroidManifest.xml file, or another part of the app that requires creating a new APK when using fast deployment mode.
Deploy and start debugging the project again in the Debug configuration.
See that the data saved in step (3) is no longer present.

brendanzagaeski commented 4 years ago

@EmilAlipiev, so far I haven't had luck reproducing the behavior where the app data is removed between deploys. Here's what I tried. Let me know if it looks like I missed anything. If these steps match what you tried, then there might be something specific happening with your app. In that case, if you might be able to collect a diagnostic MSBuild log from your project for the problematic deployment and attach it here or on a new GitHub issue (or on a new Developer Community feedback item via Help > Send Feedback > Report a Problem if it contains private information) so the team can take a look, that would be perfect. Thanks in advance!

Here's the modified version of the localization demo I used: LocalizationDemoWithAppStorage.zip

Steps I tried:

Start with one of workarounds included in the app project (I tried each one), or start without any workaround included in the app project (I tried this too).
Deploy and start debugging the project in the Debug configuration with fast deployment enabled.
Tap the Localization Xaml Demo button.
Tap the CHECK FILES button. This first updates a label on the page to indicate whether the target files already exist. Then it adds a file to the app's external storage directory as well as the app's internal storage directory.
If one of the two workarounds was not yet applied at step 1, apply one now (I tried each one).
Make a change to an Android resource, the AndroidManifest.xml file, or the MainActivity to force a new APK to be created in fast deployment mode.
Deploy and start debugging the project again in the Debug configuration.
Repeat steps 3 and 4 to check if the files still exist after the new deployment.

Results:

In all tested scenarios, after step 7, the Xamarin Diagnostics section of the Output window showed that the uninstall command included the -k (keep data and cache directories) option as expected:

pm uninstall -k "com.companyname.localizationdemo"

And after I tapped the CHECK FILES button at step 8, the label showed both files to be present:

Files: external, internal

Additional testing info:

Tested on Android 9.0 (API level 28) arm64-v8a Google Pixel 3.

Test with Visual Studio 2019 version 16.6.0.

brendanzagaeski commented 4 years ago

Release status update

A new Release version of Xamarin.Android has now been published on Windows that includes the fix for this item.

The fix is not yet available on macOS. I will update this item again when a Release version with the fix is available on macOS. If there are no unexpected complications, it will be available later this week.

Fix included in Xamarin.Android SDK version 10.3.1.4.

Fix included on Windows in Visual Studio 2019 version 16.6.1. To get the new version that includes the fix, check for the latest updates or install the most recent release from https://visualstudio.microsoft.com/downloads/. Once this update is installed, the workaround is no longer needed and can be removed from any affected projects.

Fix not yet available on macOS.

Fix not yet available in the Preview version. I will update this item again when a Preview version is available that includes the fix.

EmilAlipiev commented 4 years ago

@brendanzagaeski, thank you, update works fine. I have just tested it.

EmilAlipiev commented 4 years ago

@brendanzagaeski do you know the status of Azure Devops? How can i make sure that i am using the latest version?

brendanzagaeski commented 4 years ago

@EmilAlipiev, I haven't come across anything too fancy myself for ways to check versions on Azure DevOps. As far as I've seen, the pages linked on https://docs.microsoft.com/azure/devops/pipelines/agents/hosted have always stayed up-to-date, so I believe those pages are updated as part of the hosted image deployment process itself and are one good way to check the versions.

The Xamarin.Android build output will also find and display the active Xamarin.Android version:

_ResolveXamarinAndroidTools:
   Looking for Android NDK...
   Looking for Android SDK...
   Found Xamarin.Android 10.2.0.100

If you wish to update the Xamarin.Android SDK version before the hosted images are updated, Jonathan Peppers's boots tool can help with that. It helps download the desired Xamarin.Android SDK .vsix installer version and install as part of the Azure Pipelines build.

brendanzagaeski commented 4 years ago

Release status update

A new Release version of Xamarin.Android has now been published on macOS that includes the fix for this item to match yesterday's new version on Windows. Thanks again for submitting this issue that has helped improve the product!

Fix included in Xamarin.Android SDK version 10.3.1.4.

Fix included on macOS in Visual Studio 2019 for Mac version 8.6.2. To get the new version that includes the fix, check for the latest updates on the Stable updater channel.

(Fix also included on Windows in Visual Studio 2019 version 16.6.1. To get the new version that includes the fix, check for the latest updates or install the most recent release from https://visualstudio.microsoft.com/downloads/.)

Fix not yet available in the Preview versions. I will update this item again when Preview versions are available that include the fix.

denisjecar1 commented 4 years ago

Im having a similar issue in c# godot project, at first the strings returned only default values.

Now I can only get translation from one specific culture which is not specified as default, all other cultures return default english strings. Anyone here with same issue?

stilicode commented 4 years ago

I'm having the same issue after installing the latest mac versions (Visual Studio 8.6.2, Xamarin.Android SDK version 10.3.1.4). The fix works on the debug configuration, but when running the release configuration, only the default language is displayed.

brendanzagaeski commented 4 years ago

@denisjecar1, is your project running on Android? If your project is running on a platform other than Android, then the issue would be unrelated to this specific issue, and Stack Overflow or another project's bug tracker (perhaps Godot's bug tracker) would be able to offer better help to answer your question. This particular issue would only affect projects that use the Xamarin.Android MSBuild tasks and targets.

On the other hand, if your project is running on Android and using Xamarin.Android as part of the build process, and you are still seeing the problem after updating to the latest version of Xamarin.Android, then if there is a way to get the diagnostic MSBuild output from the build for your project and attach that on a new issue so the Xamarin.Android team can take a look, that would be perfect. Thanks in advance!

brendanzagaeski commented 4 years ago

@stilicode, thanks for the info! I double-checked the results for a Release configuration build of the https://docs.microsoft.com/xamarin/xamarin-forms/app-fundamentals/localization/text sample in Visual Studio for Mac just now, and I got the correct localizations when using the latest versions.

So there might something be different happening for your particular project.

If you could create a new issue and zip and attach the diagnostic MSBuild output from your project or a trimmed down sample project that demonstrates the problem so the team can take a look, that would be perfect. If the attachment contains private information, you can create a new Visual Studio Developer Community feedback item via Help > Send Feedback > Report a Problem in Visual Studio and attach the build output or sample project there instead. Thanks in advance!

stilicode commented 4 years ago

I did run the diagnostic MSBuild output, but that did not give any information on the problem. However, after adding a newlline in the localized resx file and rebuilding, the localization is working again for the release configuration.

denisjecar1 commented 4 years ago

@brendanzagaeski

Sorry, you are correct, its not an android project, I actually found that the issue is with mono and not Godot itself. Somehow has trouble loading same named assemblies...

Workaround for me was to use Assembly.LoadFile() for all resources dll-s, Load() and LoadFrom() do not return correct assemblies with specified culture (console app works as expected). Reported at mono project

public static void LoadAllTranslationAssemblies()
{
    string path = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
    foreach (string dll in Directory.GetFiles(path, "*.resources.dll", SearchOption.AllDirectories))
    {
        try
        {
            Assembly loadedAssembly = Assembly.LoadFile(dll);
        }
        catch (FileLoadException loadEx)
        {
            Console.WriteLine(loadEx);
        }
        catch (BadImageFormatException imgEx)
        {
            Console.WriteLine(imgEx);
        } 
    } 
}

brendanzagaeski commented 4 years ago

Release status update

The fix for this issue that was previously published in the Release versions has now been published in the latest Preview versions as well.

Fix included in Xamarin.Android SDK version 10.4.0.0.

Fix included on Windows in Visual Studio 2019 version 16.7 Preview 3. To try the Preview version that includes the fix, check for the latest updates in Visual Studio Preview.

Fix included on macOS in Visual Studio 2019 for Mac version 8.7 Preview 3. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel.

DragonTM commented 4 years ago

Hello @brendanzagaeski

Could you clarify if the fix has been included in the VS for mac 8.7.8? I still face the issue when building the app using msbuild command.

brendanzagaeski commented 4 years ago

@DragonTM, thanks for the question. Yes, the fix for this particular issue is included in Visual Studio 2019 for Mac version 8.6.2 and higher, including Visual Studio 2019 for Mac version 8.7.8.

If you could create a new issue and zip and attach the diagnostic MSBuild output from your project or attach a trimmed down sample project that demonstrates the problem so the team can take a look, that would be perfect. If the attachment contains private information, you can create a new Visual Studio Developer Community feedback item via Help > Report a Problem in Visual Studio and attach the build output or sample project there instead. Thanks in advance!

DragonTM commented 4 years ago

I will create a separate ticket for this. But leave a few comments here. It might help somebody.

I can confirm that the issue is fixed on VS for Mac. The issue is still valid for msbuild command. The workaround mentioned earlier fixes the issue for msbuild command. (https://github.com/xamarin/xamarin-android/issues/4664#issuecomment-632986668)

Kapusch commented 3 years ago

Thank you so much for the workaround @brendanzagaeski ! This saved me much time.

Indeed, this happened to me even with Visual Studio 2019 for Mac v8.8.7 (Xamarin.Android 11.1.0.26). But just after having modified my Android .csproj file, and having released a new .apk onto the Play Store, everything worked fine !

dotnet / android