Bug 31527 - Unable to load file or assembly 'System.Runtime' in project with both shared runtime and Link SDK enabled
Summary: Unable to load file or assembly 'System.Runtime' in project with both shared ...
Status: VERIFIED FIXED
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 5.2
Hardware: Macintosh Mac OS
: Highest normal
Target Milestone: 5.1.5 (C5SR3)
Assignee: dean.ellis
URL:
: 31758 ()
Depends on:
Blocks:
 
Reported: 2015-07-01 03:05 UTC by Phil Ryan
Modified: 2015-09-16 00:59 UTC (History)
11 users (show)

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


Attachments
the Application Output from Xamarin Studio for a failed build. (24.40 KB, text/plain)
2015-07-01 03:05 UTC, Phil Ryan
Details
Diagnostic Build output from a build of my app with Xamarin Android v5.1.4, "debug" build to a Xamarin Android Player Nexus 5 Lollipop phone simulator. (1.14 MB, text/plain)
2015-07-02 00:13 UTC, Phil Ryan
Details
Small project reproduicing the bug (1.84 MB, application/octet-stream)
2015-07-07 06:24 UTC, Romain Flechner
Details
Xamarin.Android.Common.targets.patch (1.90 KB, application/octet-stream)
2015-07-07 18:17 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 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:
VERIFIED FIXED

Description Phil Ryan 2015-07-01 03:05:11 UTC
Created attachment 11794 [details]
the Application Output from Xamarin Studio for a failed build.

Prior to today's update to Xamarin.Android v5.1.4, I've been unable to build my Android code including some libraries using .NET 4.5.

Errors of "java.lang.InvocationTargetException', and from the Application Output as attached.

When I downgrade back to Xamarin.Android 5.1.3.1, it works A-OK.

My creation of a "minimalist" version of my App to show the issue didn't work, in that the minimalist version of the App seems to compile and run properly.

(and one would think that if there were any leftover uncompiled old versions of code, that this process would have cleaned them out)

So, I'm willing to accept that this may be an "environmental" issue that can be corrected by a complete rebuild-from-scratch, but I have done everything that I can think of doing to "rebuild from scratch" all the included libraries and packages that are part of my app.
Comment 1 Phil Ryan 2015-07-01 04:08:33 UTC
Further testing, this time with XamAnd 5.1.3.1 but the more recent version of Mono, shows that the issue is localized to the XamAnd release.

As mentioned, this may well be an untested condition, but I would just like some better guidance as to how to get from here to there.
Comment 2 Peter Collins 2015-07-01 13:18:04 UTC
To help troubleshoot, could you please attach diagnostic build output[0] for the build attempt that ultimately results in this error?

Also, a few additional bits of environment information would likely be helpful:
1. I assume you're hitting this issue in XS on OSX?
2. Do you see this behavior for both debug and release deployments?
3. Are you seeing this error on multiple devices / emulators? Or is there a specific deployment target that is failing?

[0] http://developer.xamarin.com/guides/android/troubleshooting/troubleshooting/#Diagnostic_MSBuild_Output
Comment 3 Phil Ryan 2015-07-02 00:13:48 UTC
Created attachment 11815 [details]
Diagnostic Build output from a build of my app with Xamarin Android v5.1.4, "debug" build to a Xamarin Android Player Nexus 5 Lollipop phone simulator.

Diagnostic Build output from a build of my app with Xamarin Android v5.1.4, "debug" build to a Xamarin Android Player Nexus 5 Lollipop phone simulator.
Comment 4 Phil Ryan 2015-07-02 00:15:43 UTC
1. Yes, Xamarin Studio on OSX 10.10.3

2. I hadn't tried Release deployment until now, and am surprised that it does actually build and run on a Release deployment.

3. Multiple devices and emulators. Mainly the Xam Android Player emulators, but have tried various releases from Android v16 through to v21 Lollipop. But also tried with real Android devices: Samsung phones and Onyx tablet.
Comment 5 Atsushi Eno 2015-07-02 09:52:15 UTC
The build output says it succeeds. What is the failure?

Build: 0 errors, 41 warnings

Also what is "System.Runtime .NET stuff?"
Comment 6 Phil Ryan 2015-07-02 19:42:35 UTC
It builds, that wasn't the issue - but Peter Collins above had asked for a Diagnostic Build Output.

It builds, but then it hangs straight away not able to find System.Runtime, which is part of the .NET portable class library.

And the even weirder thing is that it is able to run with a Release build, so it is only the Debug build that it is breaking on.

And finally, this is not affected either way with the most recent Xamarin Android 5.1.4.16 that was released today. No change on this issue.
Comment 7 Peter Collins 2015-07-06 12:44:11 UTC
> And finally, this is not affected either way with the most recent Xamarin Android 5.1.4.16 that was released today.

Does this mean that you were hitting this issue on a previous version?
Comment 8 Romain Flechner 2015-07-07 05:39:01 UTC
I had the same issue.

I edited my PCL csproj manually.
Mercurial log:

@@ -22,7 +22,6 @@
     <ErrorReport>prompt</ErrorReport>
     <WarningLevel>4</WarningLevel>
     <ConsolePause>false</ConsolePause>
-    <UseVSHostingProcess>false</UseVSHostingProcess>
   </PropertyGroup>
   <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
     <DebugType>full</DebugType>
@@ -32,10 +31,6 @@
     <WarningLevel>4</WarningLevel>
     <ConsolePause>false</ConsolePause>
   </PropertyGroup>
-  <PropertyGroup>
-    <!--When building in AppHarbor, we need a project specific output folder so the assembly references don't clash with those from the plain .NET projects-->
-    <GenerateProjectSpecificOutputFolder>true</GenerateProjectSpecificOutputFolder>
-  </PropertyGroup>

I edited the Android csproj too:

@@ -20,6 +20,7 @@
     <JavaMaximumHeapSize>1G</JavaMaximumHeapSize>
     <SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\..\</SolutionDir>
     <RestorePackages>true</RestorePackages>
+	<AndroidUseSharedRuntime>True</AndroidUseSharedRuntime>
   </PropertyGroup>
   <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
     <DebugSymbols>true</DebugSymbols>
@@ -30,11 +31,7 @@
     <ErrorReport>prompt</ErrorReport>
     <WarningLevel>4</WarningLevel>
     <ConsolePause>false</ConsolePause>
-    <EmbedAssembliesIntoApk>False</EmbedAssembliesIntoApk>
-    <AndroidSupportedAbis>armeabi;armeabi-v7a;x86</AndroidSupportedAbis>
-    <MonoDroidExtraArgs>
-    </MonoDroidExtraArgs>
-    <UseVSHostingProcess>false</UseVSHostingProcess>
+    <AndroidLinkMode>None</AndroidLinkMode>
   </PropertyGroup>

   
It's now working for me.
Comment 9 Romain Flechner 2015-07-07 06:16:44 UTC
Now when I only change <AndroidLinkMode>None</AndroidLinkMode> to <AndroidLinkMode>SdkOnly</AndroidLinkMode>

I have this problem :

07-07 06:08:01.811 W/Mono    ( 9271): The following assembly referenced from /storage/emulated/0/Android/data/***********.mobileapp/files/.__override__/*********.Business.dll could not be loaded:
07-07 06:08:01.811 W/Mono    ( 9271):      Assembly:   System.Runtime    (assemblyref_index=0)
07-07 06:08:01.811 W/Mono    ( 9271):      Version:    4.0.0.0
07-07 06:08:01.811 W/Mono    ( 9271):      Public Key: b03f5f7f11d50a3a


*********.Business.dll is a PCL.
Comment 10 Romain Flechner 2015-07-07 06:24:39 UTC
Created attachment 11901 [details]
Small project reproduicing the bug


Restore Nugets, launch the app and click on the button.

It will log

[Mono] The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/storage/emulated/0/Android/data/com.companyname.xamarinbug2/files/.__override__/).
[Mono] Failed to load assembly XamarinBug2.PclOne[0xabc50100]
[Mono] Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.


Change the AndroidLinkMode value to None and it will be working.
Comment 11 Phil Ryan 2015-07-07 07:09:18 UTC
It seems that @Romain is right, if you have the AndroidLinkMode to none then it works.

From Xamarin Studio: Project Options -> Android Build -> Release -> Linker behaviour set to "don't link"

Which is strange, since just now I've gone to my App and found that I had LinkMode set to none for Release builds anyway. So, cannot explain the issue away.

Nevertheless, it does seem that AndroidLinkMode is the key here.
Comment 12 Karlo Medallo 2015-07-07 07:33:55 UTC
I was experiencing the same issue on debug build but I was able to run my app again when I disabled shared assemblies. On my release build, it was not a problem because the shared assemblies was turned off. Note that after disabling this i can set the linker back to sdk assemblies only.

Has anyone tried building a release build on OSX? Because in my case the release build worked fine in Windows but when I run it on our build server which is on OSX, the app crashes on startup.
Comment 13 Peter Collins 2015-07-07 11:49:20 UTC
This does appear to be caused by the combination of Shared Runtime + Link SDK. I can also confirm that the crash in the attached project is indeed a regression from 5.1.3.

Additional logcat output from Attachment 11901 [details]:
https://gist.github.com/pjcollins/0eb941ed46118b52a5e1
Comment 14 Jonathan Pryor 2015-07-07 17:45:09 UTC
At a high level, this looks like Bug #20179 regressed.

Rephrased: when Bug #20179 was fixed (the state of play in 5.1.3), after installing the app onto the device, the fast deployment directory contained all the facade assemblies:

https://gist.github.com/pjcollins/47fb98ea65bfcf6bc3a6
> -rw-rw---- u0_a122  sdcard_r    12800 2015-07-07 17:15 System.Runtime.dll

In 5.1.4, the facade assemblies are no longer installed:

  $ curl -o XamarinBug2.zip https://bugzilla.xamarin.com/attachment.cgi?id=11901
  $ unzip XamarinBug2.zip
  $ cd XamarinBug2
  $ xbuild /t:Install
  $ adb shell ls -l /storage/emulated/0/Android/data/com.companyname.xamarinbug2/files/.__override__/
> -rw-rw---- u0_a133  sdcard_r     4608 2015-07-07 17:43 System.Reflection.Emit.ILGeneration.dll
> -rw-rw---- u0_a133  sdcard_r     4608 2015-07-07 17:43 System.Reflection.Emit.Lightweight.dll
> -rw-rw---- u0_a133  sdcard_r     4608 2015-07-07 17:43 System.Reflection.Emit.dll
> -rw-rw---- u0_a133  sdcard_r     4096 2015-07-07 17:43 XamarinBug2.PclOne.dll
> -rw-rw---- u0_a133  sdcard_r      300 2015-07-07 17:43 XamarinBug2.PclOne.dll.mdb
> -rw-rw---- u0_a133  sdcard_r     3584 2015-07-07 17:43 XamarinBug2.PclTwo.dll
> -rw-rw---- u0_a133  sdcard_r      112 2015-07-07 17:43 XamarinBug2.PclTwo.dll.mdb
> -rw-rw---- u0_a133  sdcard_r     5632 2015-07-07 17:43 XamarinBug2.dll
> -rw-rw---- u0_a133  sdcard_r     1444 2015-07-07 17:43 XamarinBug2.dll.mdb

Consequently, System.Runtime.dll doesn't exist *anywhere*.

So something broke; the question is what.

"Fortunately," there's "only" a ~2200 line diff (20 commits) between 5.1.3 and 5.1.4:
https://github.com/xamarin/monodroid/compare/d419c934e6ce2113653ff4c40214e3a5d5a69440...5f55a9ef61c11b6ce0890bc91e4c71b1b92be214

What I *suspect* -- but haven't yet verified -- is that the breakage is due to changes within tools/msbuild (as nothing else makes sense).

Of those, <CopyMdbFiles/> isn't likely, which leaves the changes to Xamarin.Android.Common.targets, which can cause things to break by merely looking at it wrong. :-(
Comment 15 Jonathan Pryor 2015-07-07 17:51:33 UTC
@Dean: One "oddity" that we saw which just confuses matters:

The app works properly -- even when Facade assemblies aren't installed -- if you install and run via `xbuild` (as Comment #14 does), while the app fails if you install and run via Xamarin Studio. (Run the app, click the button, *BOOM*.)

Why?

Because `xbuild /t:Install` deploys obj/Debug/android/assets/*.dll to the fastdev directory, while Xamarin Studio deploys obj/Debug/assemblies. They differ; specifically, the former has been *linked* (!), and in the linking process all references to System.Runtime.dll are replaced with references to mscorlib.dll, which "magically" lets things work.

Which leaves a completely unrelated question of WHY IS THE LINKER BEING RUN FOR DEBUG BUILDS.

*cough*

(Furthemore, 5.1.3 *also* runs the linker when run from the command-line, AND it doesn't deploy the Facade assemblies when run from the command line, so there's something very confusing going on...

REGARDLESS: Debug builds should be deploying the Facade assemblies when installing from Xamarin Studio (and not linking! but separate issue). The question is why that isn't happening...
Comment 16 Jonathan Pryor 2015-07-07 18:08:58 UTC
@Dean: The interop point between monodroid and Xamarin Studio is $(IntermediateOutputPath) resolved_assemblies.txt, e.g. obj/Debug/resolved_assemblies.txt. Xamarin Studio will deploy all assemblies listed in that file:

> $ cat obj/Debug/resolved_assemblies.txt 
> .../XamarinBug2/obj/Debug/assemblies/XamarinBug2.dll
> .../XamarinBug2/obj/Debug/assemblies/XamarinBug2.PclTwo.dll
> .../XamarinBug2/obj/Debug/assemblies/XamarinBug2.PclOne.dll
> .../XamarinBug2/obj/Debug/assemblies/System.Reflection.Emit.ILGeneration.dll
> .../XamarinBug2/obj/Debug/assemblies/System.Reflection.Emit.Lightweight.dll
> .../XamarinBug2/obj/Debug/assemblies/System.Reflection.Emit.dll

Compare to 5.1.3-generated output, which DOES contain the Facade assemblies:

https://xamarinhq.slack.com/files/peterc/F07ACCX5X/resolved_assemblies_txt.txt

This in turn makes it look like the fix for Bug #30318 (commit 21b20812) may have caused the breakage.
Comment 17 Jonathan Pryor 2015-07-07 18:17:55 UTC
Created attachment 11919 [details]
Xamarin.Android.Common.targets.patch

This patch "fixes" Xamarin.Android.Common.targets by removing the parts fixed as part of Bug #30318 -- meaning this patch is probably BAD -- but in the process fixes this particular bug.

I have no idea what the implications of this patch are; I only know that after it is applied (and Xamarin Studio is restarted), resolved_assemblies.txt contains the PCLv2 facade assemblies, which allows the app to run properly.
Comment 18 Jonathan Pryor 2015-07-08 15:18:40 UTC
*** Bug 31758 has been marked as a duplicate of this bug. ***
Comment 19 dean.ellis 2015-07-08 16:46:29 UTC
Fixed in monodroid/master/48830542
Comment 20 Ram Chandra 2015-07-13 12:26:25 UTC
To verify this issue, I have checked this issue with following builds:

Mac OS X 10.10.3
Xamarin Studio : 5.9.4 (build 5)
Mono 4.0.2 ((detached/c99aa0c)
GTK+ 2.24.23 (Raleigh theme)
Package version: 400020005
Xamarin.Android: 5.1.99.486 (Enterprise Edition)
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
=== Build Information ===
Release ID: 509040005
Git revision: 8010a90f6e246b32364e3fb46ef2c9d1be9c9a2b
Build date: 2015-06-08 16:52:06-04
Xamarin addins: 7e93e9c3503f28770f23ce1b7eafd829919f18e8

Observation: I have checked this issue with all there linker behavior, i.e. "Link SDK assembly only","Link all assemblies" and "Don't link" and I am not getting the reported behavior. Application is working fine without any error/exception.

Screencast: http://www.screencast.com/t/Dsnkfthh0KI
Application Output: https://gist.github.com/RamChBachkheti/64abb7188b3b48bc6d62

This issue has been fixed. Hence I am closing this issue.