Bug 33120 - .NET Satellite dll files are not being loaded in debug or Release mode
Summary: .NET Satellite dll files are not being loaded in debug or Release mode
Alias: None
Product: Android
Classification: Xamarin
Component: Debugger ()
Version: 5.1
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2015-08-14 17:46 UTC by tstowell
Modified: 2015-09-08 20:47 UTC (History)
5 users (show)

Is this bug a regression?: ---
Last known good build:

Xamarin logs and VS Solution (3.46 MB, application/x-zip-compressed)
2015-08-21 13:38 UTC, tstowell
lowercase mx in es-mx in debug/bin output folder (56.90 KB, image/png)
2015-08-21 13:40 UTC, tstowell
Modified Test Project that works as expected. (62.22 KB, application/zip)
2015-09-08 20:47 UTC, Jon Goldberger [MSFT]

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description tstowell 2015-08-14 17:46:39 UTC
I'm using .NET satellite assemblies for localization, and found that when deploying with "Use Fast Deployment" checked in Visual Studio under Debug mode, none of the satellite dlls get loaded when running my app.

If I use msbuild (like comment 34 from this old bug: https://bugzilla.xamarin.com/show_bug.cgi?id=5037#c34) then the satellite dll folders get copied into the .__override__ folder.

I also found that when compiling in Release mode the satellite dlls are copied into the .apk file, but my app always displays English and isn't loading any of the other language resources.

It looks like bug 5037 may need to be re-opened? Although even there building in Release mode solved the issue which isn't the case now
Comment 1 asimk 2015-08-21 10:03:54 UTC
I have checked this issue with the help of bug description and not able to reproduce this issue. I followed the steps as shown in screencast: http://www.screencast.com/t/mtDeE030g

Please review the screencast and let me know what additional steps we need to follow to reproduce this issue.
Also, It would be great If you provide log details and Sample project also.
Comment 2 tstowell 2015-08-21 13:38:34 UTC
Created attachment 12602 [details]
Xamarin logs and VS Solution
Comment 3 tstowell 2015-08-21 13:40:13 UTC
Created attachment 12603 [details]
lowercase mx in es-mx in debug/bin output folder
Comment 4 tstowell 2015-08-21 13:41:10 UTC
In the screencast you used a Windows form project, but I'm having the problem in Xamarin Android. I attached a zip folder with logs and a modified VS solution based on the sample project from bug 5037. 

I also attached a screenshot that shows two folders in the bin/debug output directory, fr-CA and es-mx. The es-mx should have a capital MX, but for some reason only fr has the capital CA. The resulting apk file also has the lowercase mx which leads to the app not displaying the spanish translated text.

Note: localization won't work at all if "use shared runtime" and "use fast deployment" are checked. I had to build in release mode or debug mode with those checkboxes un-checked.
Comment 5 Dominic N [MSFT] 2015-09-02 18:04:37 UTC
Reopened. Bug needs to be verified on an Android project @asimk
Comment 6 Jon Goldberger [MSFT] 2015-09-08 20:47:07 UTC
Created attachment 12834 [details]
Modified Test Project that works as expected.

I tested this issue and was able to reproduce, but I think there was just an issue in the set up. 

To make the attached test project work as expected, two things needed to be done:

1. Change the names of the localized resx files to:

2. In the properties for the above files, add the Custom Tool:

Without 2 above the source code for the es-MX and fr-CA resx files were never generated and not having the capitals meant the resources could not be found. 

There should be a strings.xx-XX.Designer.cs file for each resx file and this is not generated without the same Custom Tool that is being used for the main strings.resx file. 

I have modified the test project with the above changes and attached it back.
Comment 7 Jon Goldberger [MSFT] 2015-09-08 20:47:25 UTC
Marking as "Answered"