Bug 54678 - Assembly.Location gives an invalid path
Summary: Assembly.Location gives an invalid path
Status: RESOLVED ANSWERED
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler ()
Version: 7.0 (C8)
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Marek Habersack
URL:
Depends on:
Blocks:
 
Reported: 2017-04-06 23:31 UTC by Frank A. Krueger
Modified: 2017-04-07 00:28 UTC (History)
2 users (show)

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


Attachments
Project demonstrating the the location doesn't exist (30.09 KB, application/zip)
2017-04-06 23:31 UTC, Frank A. Krueger
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 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:
Status:
RESOLVED ANSWERED

Description Frank A. Krueger 2017-04-06 23:31:50 UTC
Created attachment 21283 [details]
Project demonstrating the the location doesn't exist

If I call Assembly.Location in a release mode app (not a shared runtime), the paths it returns do no reference real files.

For example: typeof (object).Assembly.Location == "mscorlib.dll"

This is in contrast to debug (shared runtime) builds which produce a valid path:

/storage/emulated/0/Android/data/com.kruegersystems.asmlocation/files/.__override__/mscorlib.dll

I have attached a project that demonstrates this discrepancy.
Comment 1 Jonathan Pryor 2017-04-07 00:28:16 UTC
This is not something we wish to support.

Android .apk files have no mechanism or facility to have files extracted from the .apk at install time (*except* for native libraries, and even that is changing).

The only way we could have actual files for e.g. mscorlib.dll is if we had startup code to copy the files out of the .apk onto the disk during process startup. We actually did this before Preview 5 [0], and the startup overhead was significant. (Unfortunately, no commit message I can easily dig up actually mentions what that overhead was, but I remember it as being "bad.")

(Preview 5 took a different approach and just named all the assemblies as e.g. `libmscorlib.dll.so`, so that they'd be extracted. It was glorious! It was also deemed an incredible hack, could break without notice if Google ever used anything *other* than a file glob for library extraction, and was replaced in Preview 7 with the current infrastructure. Additionally, since Google is now looking into ways of *not* extracting native libraries from .apk files, such an idea wouldn't continue working forever.)

https://developer.xamarin.com/guides/android/under_the_hood/architecture/#Application_Packages

[0]: https://developer.xamarin.com/releases/android/previews/preview_5/