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.
Xamarin.iOS app fails when building the app to run on the device, with following exception.
Test case and build logs in the private comment below
MTOUCH: error MT2001: Could not link assemblies. Reason: Object reference not set to an instance of an object
--- inner exception
System.NullReferenceException: Object reference not set to an instance of an object
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.ProcessLoadStaticField (Mono.Cecil.MethodDefinition caller, Int32 i) <0x10e6d1420 + 0x002e8> in <filename unknown>:0
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.ProcessMethod (Mono.Cecil.MethodDefinition method) <0x10e6cf4f0 + 0x0019b> in <filename unknown>:0
at Xamarin.Linker.CoreOptimizeGeneratedCode.ProcessMethods (IEnumerable`1 c) <0x10e6ce5b0 + 0x000ab> in <filename unknown>:0
at Xamarin.Linker.CoreOptimizeGeneratedCode.ProcessType (Mono.Cecil.TypeDefinition type) <0x10e6ce490 + 0x00072> in <filename unknown>:0
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.ProcessType (Mono.Cecil.TypeDefinition type) <0x10e6ce3d0 + 0x00042> in <filename unknown>:0
at Mono.Tuner.SubStepDispatcher.DispatchType (Mono.Cecil.TypeDefinition type) <0x10dbe4d30 + 0x0006c> in <filename unknown>:0
at Mono.Tuner.SubStepDispatcher.BrowseTypes (ICollection types) <0x10dbe47b0 + 0x000a5> in <filename unknown>:0
at Mono.Tuner.SubStepDispatcher.BrowseAssemblies (IEnumerable`1 assemblies) <0x10dbe17b0 + 0x00111> in <filename unknown>:0
at Mono.Tuner.SubStepDispatcher.Process (Mono.Linker.LinkContext context) <0x10dbe0c80 + 0x00046> in <filename unknown>:0
at Mono.Linker.Pipeline.Process (Mono.Linker.LinkContext context) <0x10cca7040 + 0x000eb> in <filename unknown>:0
at MonoTouch.Tuner.Linker.Process (MonoTouch.Tuner.LinkerOptions options, MonoTouch.Tuner.MonoTouchLinkContext& context, System.Collections.Generic.List`1& assemblies) <0x10cca2ae0 + 0x00277> in <filename unknown>:0
at MonoTouch.Tuner.Linker.Process (MonoTouch.Tuner.LinkerOptions options, MonoTouch.Tuner.MonoTouchLinkContext& context, System.Collections.Generic.List`1& assemblies) <0x10cca2ae0 + 0x006e6> in <filename unknown>:0
at MonoTouch.Target.LinkAssemblies (System.String main, System.Collections.Generic.List`1& assemblies, System.String output_dir, MonoTouch.Tuner.MonoTouchLinkContext& link_context) <0x10cca1530 + 0x0051c> in <filename unknown>:0
at MonoTouch.Target.ManagedLink () <0x10cc9e670 + 0x009ae> in <filename unknown>:0
at MonoTouch.Target.ProcessAssemblies () <0x10cc9e090 + 0x0034f> in <filename unknown>:0
at MonoTouch.Application.BuildApp () <0x10cc9d760 + 0x000af> in <filename unknown>:0
at MonoTouch.Application.Build () <0x1093c5dc0 + 0x000ee> in <filename unknown>:0
at MTouch.Main2 (System.String args) <0x1092ac2d0 + 0x074c7> in <filename unknown>:0
at MTouch.Main (System.String args) <0x109200e60 + 0x00069> in <filename unknown>:0
# Version information
=== Xamarin Studio ===
Version 5.10.1 (build 6)
Installation UUID: 99b15672-d817-4a4a-a60e-5edcef4cc300
Mono 4.2.1 (explicit/6dd2d0d)
GTK+ 2.24.23 (Raleigh theme)
Package version: 402010102
=== Xamarin.Profiler ===
=== Apple Developer Tools ===
Xcode 7.2 (9548)
=== Xamarin.iOS ===
Version: 220.127.116.11 (Business Edition)
Build date: 2015-12-08 16:20:29-0500
=== Xamarin.Android ===
Version: 18.104.22.168 (Business Edition)
Android SDK: /Users/prashantvc/Library/Developer/Xamarin/android-sdk-mac_x86
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)
5.1 (API level 22)
6.0 (API level 23)
SDK Tools Version: 24.4.1
SDK Platform Tools Version: 23.0.1
SDK Build Tools Version: 22.0.1
Java SDK: /usr
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
=== Xamarin Android Player ===
Location: /Applications/Xamarin Android Player.app
=== Xamarin.Mac ===
Version: 22.214.171.124 (Business Edition)
=== Build Information ===
Release ID: 510010006
Git revision: 0b60eecdb531933734519c13257d16a780274aab
Build date: 2015-12-04 20:28:20-05
Xamarin addins: 9876fd7c9837977178411ec7375b4352c0a0d6af
Build lane: monodevelop-lion-cycle6-baseline
=== Operating System ===
Mac OS X 10.11.1
Darwin Prashants-Mac-mini.local 15.0.0 Darwin Kernel Version 15.0.0
Sat Sep 19 15:53:46 PDT 2015
The problem is in our code to remove unneeded branches for Runtime.Arch, there's a new IL sequence we don't cope with: https://gist.github.com/rolfbjarne/a00516a7ad1bab5bed0c
If this happens when using `-linksdkonly` and the error comes from
then it likely means that assembly was compiled with `[assembly: LinkerSafe]`
As a workaround try adding
in the "Additional mtouch arguments" of the project's options.
This workaround was successful. We do have the option checked for linking framework assemblies only and I added the skip linker flag to the options. I am wondering though, is there any downside to this workaround that we need to consider and if not, would this be the final solution and leave it at that?
Thanks for your help.
@Shaun, glad to hear this :-)
The downside if that it won't be processed so the output will be a bit larger. OTOH this binding assembly is small so the impact (on the final application size) should be minimal (if noticeable).
Now this will be fixed (other assemblies might be larger) and when it's released you'll be able to remove that `linkskip` from your build arguments.
Great! We really appreciate the help from all of you. Would this thread be updated when the fix is rolled out or should we just look for a package update?
The bug report will be marked RESOLVED|FIXED when the issue is fixed. Later QA will mark it as CONFIRMED.
Our products release notes includes the bug# that are fixed (e.g. ), so you'll be able to see when the fix(es) that you requires are publicly released.
The bug's milestone also gives an hint of our target. In this case it's C7 (Cycle 7) which will be our next big release. That milestone can change depending on when it's fixed or if this becomes an issue that requires fixing (e.g. no workaround) in a service release.
Fixed in maccore/master 741f6f338dcf754d795ad7f3ddb445370c983529