Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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
Created attachment 11097 [details]
Zip of example project
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.
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
=== Xamarin Studio ===
Version 5.9 (build 464)
Installation UUID: 011d70a5-dede-428b-ab04-ef451c2e539d
Mono 4.0.1 ((detached/5a0b19f)
GTK+ 2.24.23 (Raleigh theme)
Package version: 400010024
=== Apple Developer Tools ===
Xcode 6.2 (6776)
=== Xamarin.iOS ===
Version: 184.108.40.206 (Business Edition)
Build date: 2015-05-04 17:01:32-0400
=== Xamarin.Android ===
Version: 220.127.116.11 (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: 18.104.22.168 (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
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.
It works with Xamarin.iOS 22.214.171.124.
Apple documentation  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  for the lifecycle of VC for more details.
Oddly enough, this behavior appears to have reverted in 126.96.36.199.