Incompatibility with primitive array-parameters

[andersjonsson]

I think it's easier to discuss this in a PR rather than an issue.

We have a method that accepts an int[] as a parameter.

In our full framework web service that method could be called with a comma separated list of ints,
In SoapCore it needs to be called with each int wrapped in an element.

If I change the parameter in the test to
<tem:arrayOfIntParam><tem:int>1</tem:int></tem:arrayOfIntParam>
everything works, but for backwards compatibility we need this test to work.

This line assumes that there will be a wrapping element (not unreasonable).

SoapCore/src/SoapCore/XmlSerializerExtensions.cs

Line 27 in 096c5c2

while (xmlReader.IsStartElement(localname, ns))

There is also an assumption that the wrapping element will be of the service namespace, even though it should just be <int> in this case, if I'm not mistaken?

Not sure how the old api handles return values, but I'm assuming that they will be wrapped.

What is the best way to approach this? Should I just add a special case for System.Int32 like for System.Byte here:

SoapCore/src/SoapCore/SerializerHelper.cs

Line 148 in 096c5c2

if (xmlReader.HasValue && elementType?.FullName == "System.Byte")

and assume that Int32 will be the most common case for this? Might be the safest way.
The current behavior should, of course, be used as fallback.

I can't really see how string would be able to handle this behavior, for instance... But there might be an issue with the namespace assumption there also.

@kotovaleksandr I would appreciate your input here

[andersjonsson]

I added a suggested fix for int. The same strategy should work for all primitive types.
I also added a test case for both ways to send an int array.

I didn't touch the namespace bit. Should I? Or is this working as intended? In the result the type is just 1.
Maybe best to do that in a separate PR anyways

[andersjonsson]

Decided to add this handling to all primitive types except float, double, IntPtr and UIntPtr.
float and double, represented as string, contains commas. So I thought it would be best not to try any shenanigans.

That behavior is weird and, as far as I can tell, undocumented. But unfortunately our old api accepts arrays in this format without question, and we can't change the client 😢

[kotovaleksandr]

Hi @andersjonsson !

In our full framework web service that method could be called with a comma separated list of ints,

You mean asp.net asmx web services? Whats assemblies of .NET Framework depend for this feature? We can see .NET sources (https://referencesource.microsoft.com), find necessary code and transfer logic to SoapCore. What do you say?

[andersjonsson]

You mean asp.net asmx web services? Whats assemblies of .NET Framework depend for this feature? We can see .NET sources (https://referencesource.microsoft.com), find necessary code and transfer logic to SoapCore. What do you say?

Yup that's what I mean.

And apparently I am mistaken. asmx web service doesn't work with comma separated values. But it does interpret it as an empty array instead of crashing, like soapcore does.
Our method doesn't return a result (just kicks off a background task) and that background task isn't triggered in my test environment.

In order to investigate this further I created a minimal service and tried calling that. Then I realized the empty array... 🤦‍♂️

Sorry about the confusion.

I'll make some changes, to make sure that such a call just treats the result as an empty array

[andersjonsson]

There. I've removed the support for comma separated arrays and just added a .Skip() to make sure that the behavior is backwards compatible if there is a value directly in the array tag

[andersjonsson]

Now to investigate why the client hasn't realized that this call has never resulted in anything 😆

[kotovaleksandr]

Ok, thanks!