Bug 4871 - Cannot use Portable Library project Json.net library with the linker turned on
Summary: Cannot use Portable Library project Json.net library with the linker turned on
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: 5.2
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Sebastien Pouliot
Depends on:
Reported: 2012-05-03 18:50 UTC by Chris Hardy [MSFT]
Modified: 2012-05-10 10:48 UTC (History)
2 users (show)

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

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:

Description Chris Hardy [MSFT] 2012-05-03 18:50:18 UTC
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.

Error is: 
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()
Comment 1 Sebastien Pouliot 2012-05-03 19:31:39 UTC
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 [1] 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 [1] 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 [1]

[1] portable libraries are a _much_ larger subject ;-)
Comment 2 Sebastien Pouliot 2012-05-04 10:20:52 UTC
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).

5.2-series: 1748d1a5409432278d97e3200264c57761fc6aa8
master: 1f3913aa7af1eee303cc9bdd77c1e061d350829d
Comment 3 Sebastien Pouliot 2012-05-08 16:18:33 UTC
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).
Comment 4 Sebastien Pouliot 2012-05-08 21:42:34 UTC
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 ;-)
Comment 5 Sebastien Pouliot 2012-05-09 16:32:28 UTC
5.2-series: e190b525ee017b6d9a32fc517f16160abc29201b
master: 17fdbb4b668f339c8e6b4dca5a0ecc513cbfb8a9

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.
Comment 6 Sebastien Pouliot 2012-05-10 10:48:33 UTC
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).

5.2-series: 95669741405261d7babe32d5f5e84f80dde147a6
master: 38c2b02991a85c303eb292c2d0be1fae28957aa7

QA: unit tests added in both branches