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.
I cannot compile my application that uses the Json.net portable library dll when the linker is on.
Here's a project that repro's the issue: http://dl.dropbox.com/u/90453/JsonNetPortableMonoTouch.zip
The DLL was downloaded from http://json.codeplex.com/ using Json.NET 4.5 Release 4.
Linking assembly /Users/chrisntr/Projects/PortableJson/PortableJson/bin/iPhoneSimulator/Release/PortableJson.exe into /Users/chrisntr/Projects/PortableJson/PortableJson/bin/iPhoneSimulator/Release/PortableJson.app
error MT2002: Can not resolve reference: System.Void System.IO.BinaryWriter::Dispose()
The assembly was build on Windows against the MS BCL. From it's metadata:
[assembly: TargetFramework(".NETPortable,Version=v4.0,Profile=Profile2", FrameworkDisplayName = ".NET Portable Subset")]
The specific  issue is that MonoTouch (the MOBILE profile) does not include the "System.IO.BinaryWriter::Dispose()" method (it's only in NET_4_0 right now).
The means the MT (or M4A) applications, using this assembly, are broken. When JIT'ing (simulator) you may not hit the case where the missing method is required - but that does not work when using the linker since every symbol needs to be resolved (available).
It will produce broken AOT'ed binaries (for devices), if the linker is disabled, for the same reason. E.g.
> Linking symbol: '_mono_aot_module_Newtonsoft_Json_info'.
> Compiled 4321 out of 4659 methods (92%)
Ways to solve this includes:
* A specific  solution is to include this method in MOBILE (and iterate each time we hit a new one).
* Have masterinfos files built from the portable library definitions w/web reports. That would avoid finding/iterating the same fixes.
* Moving to NET_4_0 (with Mono 2.12) will solve a lot of similar issues (missing members) since NET_4_0 is generally a superset of the "portable profile" (unlike MOBILE).
* An easier (and immediate) solution is to rebuild the assembly on MonoTouch (or the upcoming MD, partial, support for portable libraries). In some cases, like this one, the code could have been compiled to uses the non-public IDisposable.Dispose (so the same code would have produced a different, working, binary once compiled). In other cases some #if will be needed.
* The "right" solution is to provide full support for portable libraries 
 portable libraries are a _much_ larger subject ;-)
A new warning (MT0011) was added when an assembly is marked as built with > NET_2_0 (e.g. NET_4_0).
Not really part of the solution(s) but it will easier to diagnose them (without asking customers for all the binaries).
Looks like MS provides XML files with their profiles. I should be able to test our own code against that with a small bit of code. That will show how much is missing (and see if we better wait for 2.12 or add them now).
I should have known better than use xml files - the one MS provides are not fully in sync with the actual metadata :-( anyway working with the .dll is not harder
Good news, for mscorlib.dll the only missing member seems to be the one you reported. System.Core has a lot but they all look related to [TypeForwardedFrom] - I simply need to handle that too.
Less happy news (not quite bad, it needs to be reviewed) is that System.xml is missing 11 members and System.ServiceModel.dll is missing 19 members. Hopefully only define adjustments... but stubs would be better than a linker error (not bug Clancey ;-)
This fix the test case* and covers .NET 4 Profile 1, 2 and 4. There's some missing stuff in Profile 3 (System.Core) that I'll look into (before closing the bug).
It also does not cover stuff that exists in unexisting assemblies (e.g. System.Net) but that's a different issue (and will require runtime support).
* Using "Link all" won't work unless you add [Preserve] methods on the metadata being used thru reflection - but using "Link SDK" works.
So, beside the actual (MonoTouch vs Profile) assembly location of the symbols, everything but System.ComponentModel.Composition (MEF) in Profile3 should be available (but not necessarily working).
QA: unit tests added in both branches