“Linked Away” exceptions. Have you seen them ?
They can sneak upon you when you switch from the simulator builds, which defaults to “Don’t link”, to device builds, which defaults to “Link SDK assemblies only”.
What’s happening ? The linker is removing code from
mscorlib.dll that cannot be used on devices. Since the method itself could not be removed (without rewriting a lot of code everywhere) the linker replaced its body with:
throw new NotSupportedException ("Linked Away");
Where ? This optimization exists only in
mscorlib.dll (so far). Some cases includes things that Mono itself does not support (e.g. Code Access Security), does not support on iOS (e.g. System.Security.AccessControl which is very Win32 specific) or that iOS disallow (e.g. requires code generation).
However there are a few, uncommon cases where the removed code could be useful (and even working). While it’s possible for the linker to be 99% right, we still need a solution for the remaining 1% – beside turning off linking completely (e.g.
--nolink) or specifically (e.g.
To cover this case the just released MonoTouch 5.0.1 includes a new option,
--nolinkaway, that allow developers to turn off this optimization. You can set it manually in MonoDevelop by using the “additional mtouch arguments” inside the project Options, iPhone Build.
This will make your
mscorlib.dll a bit larger (about 100kb) but that’s a small price to pay to get your application working 😉 E.g. when used on Touch.Unit we’re talking about 1,158,144 (
--nolinkaway --linksdk) versus 1,047,552 bytes (for
--linksdk) versus 2,484,224 bytes (
mscorlib.dll. Of course the total size would be much worse without any linking (i.e.