Bug 23503 - MT3001 Could not AOT the assembly Autofac.Extras.MvvmCross.dll
Summary: MT3001 Could not AOT the assembly Autofac.Extras.MvvmCross.dll
Alias: None
Product: iOS
Classification: Xamarin
Component: General (show other bugs)
Version: XI 8.2.0
Hardware: PC Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Zoltan Varga
Depends on:
Reported: 2014-09-30 15:14 UTC by Dominic N [MSFT]
Modified: 2014-10-02 19:16 UTC (History)
5 users (show)

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

Test Project from Customer (15.18 KB, application/zip)
2014-09-30 15:14 UTC, Dominic N [MSFT]
Verbose build output (60.07 KB, text/plain)
2014-09-30 15:15 UTC, Dominic N [MSFT]

Description Dominic N [MSFT] 2014-09-30 15:14:03 UTC
Created attachment 8260 [details]
Test Project from Customer

## Overview

We have a report of an AOT compilation error (MT3001) when deploying to an iOS device using MvvmCross. I have tested using the attached sample application on an iPhone 5 running iOS 7.0 with both the current Stable and Alpha and has been able to reproduce. Test project is attached.

## Steps to reproduce

1. Open test project in Xamarin Studio
2. Run on a physical device and note compiler error

## Actual results

App does not compile and throws an MT3001 error indicating the inability to AOT the Autofac.Extras.MvvmCros.dll assembly. I have attached my verbose build log to this report.

## Expected results

App compiles without error.

## Additional information

The original reporter of the issue indicated the MT3001 error only shows when trying to run on device. I've gone ahead and tested in the simulator and noted a System.TypeLoadException:

Could not load type 'Autofac.Extras.MvvmCross.AutofacMvxIocProvider' from assembly 'Autofac.Extras.MvvmCross

## Version information

=== Xamarin Studio ===

Version 5.5 (build 222)
Installation UUID: ee07b9c8-41e3-496f-a1ab-e8a3ed3db20f
	Mono 3.10.0 ((detached/53e3161)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 310000018

=== Apple Developer Tools ===

Xcode 6.0.1 (6528)
Build 6A317

=== Xamarin.Mac ===

Version: (Business Edition)

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: a1f0a7a
Build date: 2014-09-27 22:06:24-0400

=== Xamarin.Android ===

Version: 4.17.0 (Business Edition)
Android SDK: /Users/redacted/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		2.1    (API level 7)
		2.2    (API level 8)
		2.3    (API level 10)
		3.1    (API level 12)
		4.0    (API level 14)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.4    (API level 19)
		4.4.87 (API level 20)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

=== Build Information ===

Release ID: 505000222
Git revision: dae37674f8a41572a91bf0e14c098d15e03d0a53
Build date: 2014-09-26 14:15:04-04
Xamarin addins: bab982129fe7697d3c639fa713751ab29305a257

=== Operating System ===

Mac OS X 10.9.4
Darwin 13.3.0 Darwin Kernel Version 13.3.0
    Tue Jun  3 21:27:35 PDT 2014
    root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
Comment 2 Thomas van der Heijden 2014-09-30 19:40:00 UTC
I think I've worked out where it's going wrong.  The latest MVVMCross update added methods to the IOC interface which AutofacMvxIocProvider implements.  

Now I'm not sure what is supposed to happen here.  If AutofacMvxIocProvider is build against an older version of MvvmCross, shouldn't the compiler/linker complain?
Comment 3 Sebastien Pouliot 2014-10-02 11:34:48 UTC
The (managed) linker is not enabled, by default (it's "Link SDK"), on user* code. In fact the attached solution seems to build fine if you enabled "Link all assemblies". 

That's very likely because the new, extra/missing, references are not used (and the linker removes them without having to even resolve them).

* i.e. on non-Xamarin code

@Zoltan can you validate the above ? (if the AOT compiler crash is related to missing symbols) If so how hard would it be to issue an error ?
Comment 4 Zoltan Varga 2014-10-02 11:36:17 UTC
The error handling code in the runtime is not complete, so sometimes missing references lead to errors like this.
Comment 5 Thomas van der Heijden 2014-10-02 19:16:00 UTC
That's odd because there are explicit references to the interface and the implementation.  Why would the linker exclude them?

Note You need to log in before you can comment on or make changes to this bug.