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.
Created attachment 10881 [details]
3 sample projects to reproduce problem.
The problem is simpler to explain with a repro. It is attached.
Using Xamarin for Visual Studio 3.9.547 (latest version, at the time of writing).
Calling a WCF service, created with Visual Studio on .NET framework 4.5 and running on IIS.
The service contract is very simple:
It simply returns 0 in the first call, -1 in the next, -2 in the next, and so on.
Whenever the WCF endpoint binding is configured to use binary message encoding, and the returned number is negative, Xamarin.Android will receive a corrupt result: (-1) becomes 255, (-2) becomes 254, and so on.
When using basic HTTP binding, it works fine. Looks like some kind of deserialization issue.
Standard Microsoft .NET works fine either with or without binary message encoding.
This is probably a duplication of bug #18578, only it applies to 'int' instead of float, and the only way I could submit a repro as an attachment was to file a new bug.
Repro includes 3 projects: the WCF service, the Android client and a Windows Console Application client, which I used to compare MS .NET results with Mono for Android results.
It is most likely fixed in the next version that will be based on mono 4.20 because our System.Runtime.Serialization switched to MS referencesource. Our System.ServiceModel cannot switch yet, so old code may still bite.