Bug 36514 - [VS only] The "fast deployment" process does not automatically update the class library assemblies on device after an upgrade from XA 5.1 to XA 6.0, leading to "Assertion at ... class.c:5078, condition `class' not met"
Summary: [VS only] The "fast deployment" process does not automatically update the cla...
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: Android ()
Version: unspecified
Hardware: PC Windows
: High major
Target Milestone: ---
Assignee: dean.ellis
: 34239 36179 ()
Depends on:
Reported: 2015-12-03 04:23 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2016-10-08 11:36 UTC (History)
11 users (show)

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

Log files (7.22 KB, application/zip)
2015-12-03 04:23 UTC, Brendan Zagaeski (Xamarin Team, assistant)

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 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 Brendan Zagaeski (Xamarin Team, assistant) 2015-12-03 04:23:27 UTC
Created attachment 14094 [details]
Log files

[VS only] The "fast deployment" process does not automatically update the class library assemblies on device after an upgrade from XA 5.1 to XA 6.0, leading to "Assertion at ... class.c:5078, condition `class' not met"

## Workarounds observed to stop the problem for the test scenario described below

Manually uninstall the app from the Android emulator after step 9 fails. Then repeat step 9.

(If using `adb uninstall` to uninstall the app, be sure _not_ to pass the `-k` option. It is important to clear all of the application data.)

### More minimal workaround, for illustrative purposes only

For the _precise_ scenario described below it is sufficient to delete just the old `mscorlib.dll` from the "fast deployment" directory before step 9:

> adb shell rm /sdcard/Android/data/AndroidApp1.AndroidApp1/files/.__override__/mscorlib.dll

## Objectives of this bug

Based on the "minimal workaround," it seems that the "condition `class' not met" error arises when the Mono base class library versions that are installed for a particular app on the device are mismatched with the current Mono runtime version that is installed on the device. That result itself probably isn't too surprising from the perspective of the Mono runtime team, so the end goals of this bug might really be:

1. Decide on when the IDEs should update the fast deployment directory and which assemblies should be updated.

2. Ensure that the fast deployment behavior is consistent across IDEs as well as across Mac and Windows.

3. Add useful related error messages at build time or at run time. For example, perhaps a specific run-time error message could be added for the case where a version mismatch is detected between the Mono runtime and the Mono base class libraries.

(If it is technically feasible, one possible approach that could mostly address the whole problem could be to force a full reinstall of the fast deployment directory any time the on-device application is detected to have been built with an older version of Xamarin.Android than the current version being used to deploy.)

## Problem history: not exactly a regression

It could maybe be argued that this issue is more of a "new feature bug" rather than a regression.

- In XamarinVS 3.9.547 (Xamarin.Android 4.20), the only file that was uploaded to the fast deployment directory was the application assembly itself, and that assembly is always updated correctly (at least in the context of this bug).

- Starting sometime after the initial Cycle 5 release (XamarinVS 3.11.445) and before the last Cycle 5 service release (SR 5, XamarinVS 3.11.1594), the Xamarin.Android deployment process started to upload additional class library assemblies (such as `mscorlib.dll`) into the fast deployment directory.

- The fast deployment behavior in Cycle 6 is _unchanged_ compared to Cycle 5 SR 5, but the Mono runtime has now changed sufficiently that the class libraries in the fast deployment directory _must_ be refreshed after the development PC has been upgraded to Cycle 6. This is a scenario that had never occurred before Cycle 6.

## Steps followed to reproduce

1. Install Xamarin.VisualStudio_3.11.1594.msi.

2. Create a default Android "Blank" application template project

3. Click the "start debugging" button to build and deploy the app in the "Debug" configuration. (Tested with the Xamarin Android Player (KitKat).)

4. Stop debugging.

5. Save the solution and quit Visual Studio.

6. Install Xamarin.VisualStudio_4.0.0.1697.msi.

7. Open the saved solution in Visual Studio.

8. Open "MainActivity.cs", change "clicks" to "click", and save the change. (Any change will work. The idea is just to make sure that VS does the build + deploy steps rather than simply launching the existing previously deployed app.)

9. Click the "start debugging" button.

## Results

The app attempts to launch on the emulator at step 9, but it immediately crashes due to a failed Mono assertion (visible in the adb logcat output):

> * Assertion at /Users/builder/data/lanes/2098/3efa14c4/source/mono/mono/metadata/class.c:5078, condition `class' not met

### The class libraries in the fast deployment directory are not updated after step 9

I gathered the output of the following command before and after step 9:

> adb shell ls -l /sdcard/Android/data/AndroidApp1.AndroidApp1/files/.__override__/

Based on the timestamps from that output, the _only_ file that is updated during step 9 is the application assembly itself: "AndroidApp1.dll". None of the other assemblies are updated. For example, neither "Mono.Android.dll" nor "mscorlib.dll" is updated.

(See also the "FastDevOverrideFolder*.txt" files in the attached logs.)

## Xamarin Studio does _not_ show the same problem, at least for this particular scenario

I tested steps 1 - 9 in Xamarin Studio on Windows.

I also tested on Mac using the appropriate installer packages for steps 1 and 6:

1. mono-android-5.1.9-0.pkg 

6. mono-android-6.0.0-34.pkg 

I was unable to reproduce the problem in Xamarin Studio on either Windows or Mac. According to the timestamps, every file in the fast deployment directory [1] was updated during the second deployment at step 9.

(There is in fact a chance that this "better" behavior (in the context of this bug) might actually indicate a missing optimization in the Xamarin Studio fastdev deployment process that is present in the XamarinVS deployment process. I did confirm that the "Preserve data/cache between application deploys" IDE option was enabled, and I further confirmed that all of the timestamps were _not yet changed_ at the beginning of the "Synchronizing assemblies" phase, indicating that the files had (correctly) not been removed during the "Removing previous version of application" deployment phase.)

> [1] /sdcard/Android/data/AndroidApp1.AndroidApp1/files/.__override__/
Comment 1 Brendan Zagaeski (Xamarin Team, assistant) 2015-12-03 04:24:34 UTC
*** Bug 34239 has been marked as a duplicate of this bug. ***
Comment 2 Brendan Zagaeski (Xamarin Team, assistant) 2015-12-03 04:25:53 UTC
*** Bug 36179 has been marked as a duplicate of this bug. ***
Comment 3 dean.ellis 2015-12-07 16:14:36 UTC
I found the root cause of the issue.

In the 3.11 there seems to have been a bug in the "Install" targets for Xamarin.Android which deployed the Framework assemblies (mscorelib) to the .__override__ directory when the project was using the shared runtime. 

This issue seems to have been fixed in cycle 6, and when using the shared runtime we now only deploy the User assemblies to the .__override__ directory. 

As a result the "old" files are not removed/overwritten. I'll look into adding a check to remove any .dll/mdb files from that directory that we are NOT expecting to be in there, that should fix the issue, or we could detect the shared runtime version change and force an uninstall of that app.
Comment 6 Peter Collins 2015-12-15 16:08:11 UTC
Marking as fixed as per Comment #5, and now that all products have updated androidtools references including this fix.
Comment 7 Brendan Zagaeski (Xamarin Team, assistant) 2015-12-15 18:33:00 UTC
## Status update for any users CC'd on the bug

The candidate fix for this issue is not yet included in the preliminary Alpha version of "Cycle 6 – Service Release 1" published on December 10, but that is mostly because those builds are still just early Alpha versions. The candidate fix will likely be included in a future preview version of "Cycle 6 – Service Release 1."
Comment 8 Peter Collins 2016-01-11 16:25:46 UTC
Unfortunately, it doesn't look like this is going to be included in the C6SR1 release.
Comment 9 Brendan Zagaeski (Xamarin Team, assistant) 2016-01-11 17:39:51 UTC
## Status update for any users CC'd on the bug

It turned out the initial candidate fix mentioned in Comment 7 did not behave as expected after further testing. A new fix is in progress but it is not ready for inclusion in "Cycle 6 – Service Release 1". So for the time being users will need to continue to use the workaround from Comment 0.

The new candidate fix will hopefully be included in the next release.
Comment 10 Abhishek 2016-04-26 17:21:24 UTC
I have checked this issue and able to reproduce this issue at my end with the following build:

I have followed the steps given in the bug description.

Debug Output: https://gist.github.com/Abhishekk360/43fce57718653281d0ebfa75db9560b6

I have checked this issue with latest C7 build:
I have followed the steps mention on description of the bug.I have created the application with XVS 3.11.1587 and deploy the application on Device/Emulator by clicking on "start debugging". Then I installed then new C7 xvs build and open the same application make changes on MainActivity file, deploy the application by clicking "start debugging".

Application deploy successfully on device without any crash. 

Screencast: http://www.screencast.com/t/kVMqToQ01yE
Debug Output: https://gist.github.com/Abhishekk360/c406c68f666307aa7e1d65dd5df3db6e

As if now I am closing this issue.Please feel free to reopen this issue if you face this issue again.

Comment 11 Mikalai Daronin 2016-09-14 08:55:50 UTC
Just received `AOT module 'mscorlib.dll.so' not found` error in my application with Xamarin 4.2 on Windows - similar to Bug 36179.

Android project configuration:
Use Shared Mono Runtime - NO
Fast Assembly Deployment - NO
Linker - Don't Link
Supported ABIs: armeabi, armeabi-v7a, x86

Device log: https://gist.github.com/lassana/fd361d20c5c5f6daad64f13d52bdbc16

I've rolled back to 4.1.2 version and the problem went away.

Is it regression or am I doing something wrong?
Comment 12 Brendan Zagaeski (Xamarin Team, assistant) 2016-09-14 18:12:11 UTC
@Nikolai, the message you're seeing about mscorlib.dll.so (as compared to mscorlib.dll in Comment 0) is in fact ignorable (see Bug 42933).

Please file a new bug against Xamarin 4.2 for the issue you're seeing.  If possible, please include the following additional information (along with the nice log file you've already collected):

- Do you get the same problem with a new template Xamarin.Android or Xamarin.Forms app?

- If not, then if possible, please attach a small, self-contained test case on the new bug report that reproduces the bug with as little code as possible.

See https://developer.xamarin.com/guides/cross-platform/troubleshooting/questions/howto-file-bug/ for additional details on what to include.  Thanks in advance!

(In case it's helpful, new bug reports are encouraged by default because comments on "verified fixed" bugs aren't as visible to the engineering team for prioritization as new bug reports.  Thanks much!)
Comment 13 Mikalai Daronin 2016-10-08 11:36:34 UTC
Hi @Brendan!

My apologies for the delay.
I've created a new Bug 45212. Please let me know if there are some other information which I should present.