Bug 3494 - Multidimensional results from a SOAP call not handled correctly
Summary: Multidimensional results from a SOAP call not handled correctly
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: 5.2
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2012-02-16 08:42 UTC by Jason
Modified: 2015-05-14 16:14 UTC (History)
3 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 Jason 2012-02-16 08:42:54 UTC
Mono 2.10.8, monodevelop, Monotouch 5.2.4

Not sure if this is a bug or a genuine feature limitation but I have a return from a SOAP call that doesnt seem to be handled correctly (gives a runtime error).

The problem appears to lie within XmlSerializationReader.cs in the ReadList function at around line 550. During variable setup this function attempts to parse an XML Qualified Name to work out the number of parameters its going to be returning. When presented with the following name: 


it correctly identifies the start of the parameter array bounds at the open-square-bracket, but the following lines include an attempt to turn the value inside the square-brackets into an integer.

This will work on a single-dimension (eg, [999]) but on a multiple dimension it will try and parse something along the lines of "2,5" into an integer, causing the runtime error.

What would be ideal here would be an elaborate nesting of parameter creation to produce a multi=dimensional output however any valid output would be usable, even if its a single dimension array containing semi-processed output. Semi-processed output could probably be quickly solved by trapping for a comma and only using the first dimension parameter (eg the "2" in "2,5").

Hope this helps.
Comment 1 Rolf Bjarne Kvinge [MSFT] 2012-02-17 07:28:23 UTC
Do you have a test case where we can reproduce it? It would likely speed up a fix (since we don't have to create a test case first).
Comment 2 Jason 2012-02-21 06:59:45 UTC
While researching a simple way of making a test case on this, I came across an article about .NETs XML Serializer and its limitations, they mentioned only one dimension there so it looks like a genuine limitation. Ive coded around it by adding a serverside call to return the information as a single dimension.

Unless anyone thinks this should be kept open for producing a non-descript error message, I guess this can be closed.
Comment 3 Sebastien Pouliot 2015-05-14 16:14:24 UTC
Closing (genuine limitation as stated in comment #2).