Bug 11430 - mkbundle doesn't support satellite assemblies
Summary: mkbundle doesn't support satellite assemblies
Status: VERIFIED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: Tools (show other bugs)
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: 4.8.0 (C9)
Assignee: Marek Habersack
URL:
: 41180 (view as bug list)
Depends on:
Blocks: 15948
  Show dependency tree
 
Reported: 2013-03-26 15:27 UTC by Jonathan Pryor
Modified: 2017-01-13 02:44 UTC (History)
6 users (show)

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


Attachments
Scratch.I18n.zip (17.02 KB, application/zip)
2013-03-26 15:27 UTC, Jonathan Pryor
Details


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 GitHub or Developer Community 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:
Status:
VERIFIED FIXED

Description Jonathan Pryor 2013-03-26 15:27:02 UTC
Created attachment 3700 [details]
Scratch.I18n.zip

(~same as Bug #5037)

mkbundle doesn't support multiple resource assemblies.

Consider Scratch.I18n.zip, which it includes localizations for 3 cultures
(fallback, fr-CA, de-DE) and it uses the
ResourceManager.GetString(string, CultureInfo) overload to use all cultures.

So let's use it with mkbundle:

    $ unzip Scratch.I18n.zip
    $ cd Scratch.I18n
    $ xbuild
    $ AS="as -arch i386" \
      CC="cc -m32" \
      PKG_CONFIG_PATH=/Library/Frameworks/Mono.framework/Libraries/pkgconfig \
      mkbundle --deps --keeptemp -o i18n bin/Debug/*.dll bin/Debug/*/*.dll

This is with Mono 3.0.6 on OS X.

The result of the mkbundle command is that it doesn't build:

> OS is: Darwin
> Sources: 5 Auto-dependencies: True
>    embedding: /Users/jon/Development/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/MyResources.dll
>    embedding: /Library/Frameworks/Mono.framework/Versions/3.0.6/lib/mono/4.5/mscorlib.dll
>    embedding: /Users/jon/Development/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/de-DE/MyResources.resources.dll
>    embedding: /Users/jon/Development/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/de-DE/Scratch.I18n.resources.dll
>    embedding: /Users/jon/Development/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/fr-CA/MyResources.resources.dll
>    embedding: /Users/jon/Development/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/fr-CA/Scratch.I18n.resources.dll
> Compiling:
> as -arch i386 -o temp.o temp.s 
> temp.s:2949153:FATAL:Symbol _assembly_data_MyResources_resources_dll already defined.
> [Fail]

The cause for this is that mkbundle assumes that filenames are unique, which is
not the case once resource assemblies are introduced, as we have _two_
MyResources.resources.dll assemblies, resulting in "double duplication."

This is a mkbundle bug, which can be fixed by e.g. encoding the
culture into the name. However, that brings us to the next deficiency:
mono_register_bundled_assemblies() and the associated bundle framework only
deals with filenames, not path names.
Comment 2 Artur Kraev 2013-06-13 11:54:11 UTC
You may see patched version of mkbudle which name mkbundlex:

https://github.com/RaveNoX/mkbundlex

This version makes deps resolution like mono or .Net
Comment 3 Jonathan Pryor 2016-05-25 15:14:54 UTC
*** Bug 41180 has been marked as a duplicate of this bug. ***
Comment 4 Michael Dimoudis 2016-05-30 03:06:55 UTC
Hi Jonathan

I saw your comment on https://github.com/Humanizr/Humanizer/issues/556

I've attached the APK which I think has embedded assemblies with Humanizr still there. You can download it here https://secure.webpanache.com.au/com.pageuppeople.performanceeveryday.apk.zip . Are you able to confirm that this APK actually does or does not have embedded assemblies? This APK was built with embed assemblies on, ProGuard and Multi-Dex on too. AOT was turned off.

Also if I can't get embed assemblies working, instead of removing Humanizr, would simply AOT and LLVM compiling the APK be pretty much the same/similar thing to prevent decompilation?

Thanks
Comment 5 Michael Dimoudis 2016-05-30 03:09:58 UTC
Sorry posted above comment in wrong bugzilla bug and couldn't delete it :(
Comment 6 Jonathan Pryor 2016-05-31 19:20:24 UTC
> Are you able to confirm that this APK actually does or does not have embedded assemblies? 

No, as I cannot access that URL.

> would simply AOT and LLVM compiling the APK be pretty much the
> same/similar thing to prevent decompilation?

Not at this time. AOT is simply used to avoid JIT-related overheads. The assembly is still embedded into the .apk and is unchanged.

We are investigating ways to do *some* IL stripping when using AOT, but there would be limitations, e.g. generic types+methods would NOT be stripped, making the entire feature questionable. There is no timeframe for this work being completed.
Comment 7 Brendan Zagaeski (Xamarin Team, assistant) 2017-01-13 02:39:58 UTC
## Status and bookkeeping update

The fix for this was prepared and recorded on non-public Bug 27061 around September.

On mono/master: https://github.com/mono/mono/commit/787b047886da494ec2f05a2db86baca33a9f39f7

Backported to mono/mono-4.8.0-branch, commit af086b0c70e4742669618b120b5a9681218e9fbd




## Steps followed to test

I followed the steps from Comment 0, with a couple small modifications: (a) I added a symlink for `pkg-config` on my $PATH for my convenience in testing and (b) I added the new required `--i18n` argument for `mkbundle`.

  $ unzip Scratch.I18n.zip
  $ sudo ln -s /Library/Frameworks/Mono.framework/Versions/4.8.0/bin/pkg-config32 /usr/local/bin/pkg-config
  $ cd Scratch.I18n/Scratch.I18n
  $ xbuild
  $ AS="as -arch i386" \
      CC="cc -m32" \
      PKG_CONFIG_PATH=/Library/Frameworks/Mono.framework/Libraries/pkgconfig \
      mkbundle --deps --keeptemp --i18n none -o Scratch bin/Debug/*.dll bin/Debug/*/*.dll




## Verification status: verified fixed in Mono 4.8.0 (Cycle 9)



### GOOD results with Mono 4.8.0 (mono-4.8.0-branch/9e8f0ee)

`mkbundle` completes successfully:

> Storing satellite assembly '/Users/Shared/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/de-DE/MyResources.resources.dll' with name 'de-DE/MyResources.resources.dll'
> Storing satellite assembly '/Users/Shared/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/de-DE/Scratch.I18n.resources.dll' with name 'de-DE/Scratch.I18n.resources.dll'
> Storing satellite assembly '/Users/Shared/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/fr-CA/MyResources.resources.dll' with name 'fr-CA/MyResources.resources.dll'
> Storing satellite assembly '/Users/Shared/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/fr-CA/Scratch.I18n.resources.dll' with name 'fr-CA/Scratch.I18n.resources.dll'
> Storing satellite assembly '/Users/Shared/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/de-DE/MyResources.resources.dll' with name 'de-DE/MyResources.resources.dll'
> Storing satellite assembly '/Users/Shared/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/de-DE/Scratch.I18n.resources.dll' with name 'de-DE/Scratch.I18n.resources.dll'
> Storing satellite assembly '/Users/Shared/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/fr-CA/MyResources.resources.dll' with name 'fr-CA/MyResources.resources.dll'
> Storing satellite assembly '/Users/Shared/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/fr-CA/Scratch.I18n.resources.dll' with name 'fr-CA/Scratch.I18n.resources.dll'
> 
> Generated Scratch


### BAD results with Mono 4.6.2 (mono-4.6.0-branch/ac9e222)

> OS is: Darwin
> Sources: 5 Auto-dependencies: True
> ERROR: Duplicate assembly name `MyResources.resources.dll'. Both `/Users/Shared/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/fr-CA/MyResources.resources.dll' and `/Users/Shared/Projects/Scratch.I18n/Scratch.I18n/bin/Debug/de-DE/MyResources.resources.dll' use same assembly name.
(The wording of the error changed a bit compared to Comment 0 due to some earlier changes in `mkbundle` that provided a more descriptive error message for this scenario.)




## Additional testing environment info (brief)

Mac OS 10.11.6