Bug 29803 - TargetInvocationException thrown from constructor
Summary: TargetInvocationException thrown from constructor
Status: RESOLVED FEATURE
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: XI 8.10
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2015-05-06 12:52 UTC by Corey Sunwold
Modified: 2015-07-10 14:27 UTC (History)
3 users (show)

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


Attachments
Zip of example project (181.81 KB, application/x-zip-compressed)
2015-05-06 12:52 UTC, Corey Sunwold
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 FEATURE

Description Corey Sunwold 2015-05-06 12:52:04 UTC
The attached code sample throws this exception when run in either a simulator or on a device if built with Xamarin.iOS 8.10. This does not happen in previous versions.

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Exception: Unable to resolve type: FailingTasks.MyClass ---> System.Exception: Unable to resolve type: System.Reactive.Concurrency.IScheduler
at TinyIoC.TinyIoCContainer.ResolveInternal (TinyIoC.TypeRegistration registration, TinyIoC.NamedParameterOverloads parameters, TinyIoC.ResolveOptions options) [0x00220] in /Users/corsun/Projects/FailingTasks/iOS/TinyIoC.cs:3557
at TinyIoC.TinyIoCContainer.ConstructType (System.Type requestedType, System.Type implementationType, System.Reflection.ConstructorInfo constructor, TinyIoC.NamedParameterOverloads parameters, TinyIoC.ResolveOptions options) [0x000e9] in /Users/corsun/Projects/FailingTasks/iOS/TinyIoC.cs:3763
--- End of inner exception stack trace ---
at TinyIoC.TinyIoCContainer.ConstructType (System.Type requestedType, System.Type implementationType, System.Reflection.ConstructorInfo constructor, TinyIoC.NamedParameterOverloads parameters, TinyIoC.ResolveOptions options) [0x000fb] in /Users/corsun/Projects/FailingTasks/iOS/TinyIoC.cs:3773
at TinyIoC.TinyIoCContainer.ConstructType (System.Type requestedType, System.Type implementationType, TinyIoC.NamedParameterOverloads parameters, TinyIoC.ResolveOptions options) [0x00008] in /Users/corsun/Projects/FailingTasks/iOS/TinyIoC.cs:3724
at TinyIoC.TinyIoCContainer.ResolveInternal (TinyIoC.TypeRegistration registration, TinyIoC.NamedParameterOverloads parameters, TinyIoC.ResolveOptions options) [0x0020e] in /Users/corsun/Projects/FailingTasks/iOS/TinyIoC.cs:3553
at TinyIoC.TinyIoCContainer.Resolve (System.Type resolveType) [0x00012] in /Users/corsun/Projects/FailingTasks/iOS/TinyIoC.cs:1566
at TinyIoC.TinyIoCContainer.Resolve[MyClass] () [0x0000c] in /Users/corsun/Projects/FailingTasks/iOS/TinyIoC.cs:1685
at FailingTasks.iOS.ViewController..ctor (IntPtr handle) [0x00015] in /Users/corsun/Projects/FailingTasks/iOS/ViewController.cs:15
at at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (System.Reflection.MonoCMethod,object,object[],System.Exception&)
at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters) [0x00002] in /Users/builder/data/lanes/1503/6481535e/source/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:535
--- End of inner exception stack trace ---
at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters) [0x00016] in /Users/builder/data/lanes/1503/6481535e/source/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:541
at System.Reflection.MonoCMethod.DoInvoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00095] in /Users/builder/data/lanes/1503/6481535e/source/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:526
at System.Reflection.MonoCMethod.Invoke (BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in /Users/builder/data/lanes/1503/6481535e/source/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:554
at System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters) [0x00000] in /Users/builder/data/lanes/1503/6481535e/source/mono/mcs/class/corlib/System.Reflection/ConstructorInfo.cs:62
at ObjCRuntime.Runtime.ConstructNSObject[NSObject] (IntPtr ptr, System.Type type, MissingCtorResolution missingCtorResolution) [0x0003e] in /Users/builder/data/lanes/1503/6481535e/source/maccore/src/ObjCRuntime/Runtime.cs:685
at ObjCRuntime.Runtime.ConstructNSObject (IntPtr ptr, IntPtr klass, MissingCtorResolution missingCtorResolution) [0x00013] in /Users/builder/data/lanes/1503/6481535e/source/maccore/src/ObjCRuntime/Runtime.cs:666
at ObjCRuntime.Runtime.GetNSObject (IntPtr ptr, MissingCtorResolution missingCtorResolution, Boolean evenInFinalizerQueue) [0x00022] in /Users/builder/data/lanes/1503/6481535e/source/maccore/src/ObjCRuntime/Runtime.cs:764
at ObjCRuntime.Runtime.TryGetOrConstructNSObjectWrapped (IntPtr ptr) [0x00000] in /Users/builder/data/lanes/1503/6481535e/source/maccore/src/ObjCRuntime/Runtime.cs:355
at ObjCRuntime.Runtime.try_get_or_construct_nsobject (IntPtr obj) [0x00000] in /Users/builder/data/lanes/1503/6481535e/source/maccore/runtime/Delegates.generated.cs:190
at at (wrapper native-to-managed) ObjCRuntime.Runtime:try_get_or_construct_nsobject (intptr)
at at (wrapper managed-to-native) UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr)
at UIKit.UIApplication.Main (System.String[] args, IntPtr principal, IntPtr delegate) [0x00005] in /Users/builder/data/lanes/1503/6481535e/source/maccore/src/UIKit/UIApplication.cs:63
at UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x00038] in /Users/builder/data/lanes/1503/6481535e/source/maccore/src/UIKit/UIApplication.cs:47
at FailingTasks.iOS.Application.Main (System.String[] args) [0x00008] in /Users/corsun/Projects/FailingTasks/iOS/Main.cs:17
Comment 1 Corey Sunwold 2015-05-06 12:52:36 UTC
Created attachment 11097 [details]
Zip of example project
Comment 2 Rajneesh Kumar 2015-05-06 13:14:36 UTC
I have checked this issue and able to reproduce this. To reproduce this issue I have followed the steps and instruction provided in bug description.

Steps I followed:

1. Open attached test case in XS.
2. build and deploy the application on emulator.
3. Observed that on deploying it throws TargetInvocationException. 

Screencast: http://www.screencast.com/t/z2RNAKgKHmRI

Application output: https://gist.github.com/Rajneesh360Logica/6b5f620e2dac593d22c4
iOS Designer Logs: https://gist.github.com/Rajneesh360Logica/52a130a58074cd617abe
Ide Logs: https://gist.github.com/Rajneesh360Logica/3480069f9d386a2afa80
Emulator Logs: https://gist.github.com/Rajneesh360Logica/62f6951c0839e4f8626c

Environment Info:

=== Xamarin Studio ===

Version 5.9 (build 464)
Installation UUID: 011d70a5-dede-428b-ab04-ef451c2e539d
Runtime:
	Mono 4.0.1 ((detached/5a0b19f)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 400010024

=== Apple Developer Tools ===

Xcode 6.2 (6776)
Build 6C131e

=== Xamarin.iOS ===

Version: 8.10.1.24 (Business Edition)
Hash: 1b48440
Branch: master
Build date: 2015-05-04 17:01:32-0400

=== Xamarin.Android ===

Version: 5.1.0.129 (Business Edition)
Android SDK: /Users/MM/Desktop/android-sdk-macosx
	Supported Android versions:
		2.3    (API level 10)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
		5.0    (API level 21)
Java SDK: /usr
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)

=== Xamarin Android Player ===

Version: Unknown version
Location: /Applications/Xamarin Android Player.app

=== Xamarin.Mac ===

Version: 2.0.1.24 (Business Edition)

=== Build Information ===

Release ID: 509000464
Git revision: 97f3c43266a4abe2dff0a31b1afb976de897d099
Build date: 2015-05-04 10:06:54-04
Xamarin addins: 438f3e4b8352e006958552de07c6f54770c9233c

=== Operating System ===

Mac OS X 10.9.5
Darwin MacMini.local 13.4.0 Darwin Kernel Version 13.4.0
    Sun Aug 17 19:50:11 PDT 2014
    root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64
Comment 3 Sebastien Pouliot 2015-05-06 17:01:53 UTC
Which was your previous, working, version of XI ?

The resolve calls seems to work fine if done later, e.g. if done in ViewDidLoad.

That _seems_ to be because the initialization in FinishedLaunching has not yet been called* when the ViewController is called (by iOS). Moving the call to ViewDidLoad change the call order so FinishedLaunching is called before.

* that's normal, it's a VC associated to a storyboard and iOS will initialize it _before_ telling you it has finished launching the app. If your TinyIoC initialization is required before this then you need to ensure it's called before that.
Comment 4 Corey Sunwold 2015-05-06 17:17:40 UTC
It works with Xamarin.iOS 8.6.1.26.
Comment 5 Sebastien Pouliot 2015-05-08 11:58:57 UTC
Apple documentation [1] states that `application:willFinishLaunchingWithOptions:` is called after the storyboard is loaded - which means after the managed constructor was be called.

> This method is called after your app has been launched and its main storyboard or nib file has been loaded,

so the current behaviour is correct. 

I'm not sure why it worked with 8.6 (I verified it and you're right that the order was different). I suspect it's a minor runtime change/optimization that affected timing of how events were queued into the run loop.

Note that the constructors (init*) of view controllers is often a bad place for adding custom code. In this case it does not affect the VC/View itself (which is a common mistake) but it does affect your application load time (which is limited) for something you can likely delay (after the launch). See Figure 4-1 of [2] for the lifecycle of VC for more details.

[1] https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplicationDelegate_Protocol/

[2] https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/ViewLoadingandUnloading/ViewLoadingandUnloading.html
Comment 6 Corey Sunwold 2015-07-10 14:27:06 UTC
Oddly enough, this behavior appears to have reverted in 8.10.3.2.