Question

I have a .NET web service which I would like to have accept either List<int> foo or int[] foo. I’ve tried declaring the paramater as each of those types, but it is converted to an ArrayOfInt after being ran through the serializer.

I have another web service which is implemented differently (old, moving to new structure) and, as such, it does not use System.Runtime.Serialization to generate its reference. This has the beneficial side-effect of not turning an int[] parameter into ArrayOfInt.

Interestingly enough, my web service’s method happily returns int[]. It just will not accept int[] as parameter:

[WebMethod(Description = "Gets a list of Tasks from a list of Order IDs.")]
public List<TaskDto> GetTasksByIDList(int[] idList)
{
    return new List<TaskDto>();
}

[Test]
public void GetTasksByIDList()
{
    Task taskDto = WorkflowServices.CreateInstallTask(OrderID, TaskTemplateID, SiteID, DataCenterID,
                                                         DeviceTemplateID, DeviceName, Username);

    Task secondTaskDto = WorkflowServices.CreateInstallTask(OrderID, TaskTemplateID, SiteID, DataCenterID,
                                             DeviceTemplateID, DeviceName, Username);

    ArrayOfInt idList = new ArrayOfInt{ taskDto.ID, secondTaskDto.ID };

    List<Task> tasks = WorkflowServices.GetTasksByIDList(idList).ToList();

    if (tasks.Count() != idList.Count())
        throw new Exception(string.Format("Failed to find {0} tasks by ID. Received: {1}", idList.Count(), tasks.Count()));
}

Any ideas on how I can convince my service to accept int[] instead of ArrayOfInt? I do not want an end user to have to understand what/why an ArrayOfInt collection is necessary for only some scenarios and not others.

UPDATE:

Here’s some more information regarding this issue. First, a screenshot of a web service I consider to be generated properly. Note that the WSDL declaration indicates ArrayOfInt, but it is still interpreted as int[]:

Now, by contrast:

And here’s the top of each of their Reference.cs files. Note that the ‘good’ service reference is generated using ServiceModel, but the ‘bad’ service reference does not.

namespace CableSolve.Web.Api.Tests.ComponentServicesProxy {
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
[System.ServiceModel.ServiceContractAttribute(Namespace="http://www.cormant.com/cswebapi", ConfigurationName="ComponentServicesProxy.ComponentServicesSoap")]
public interface ComponentServicesSoap {

namespace CableSolve.Web.Api.Tests.WorkflowServicesProxy {
    using System.Runtime.Serialization;
    using System;
    [System.Diagnostics.DebuggerStepThroughAttribute()]
    [System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "4.0.0.0")]
    [System.Runtime.Serialization.DataContractAttribute(Name="Order", Namespace="http://www.cormant.com/cswebapi")]
    [System.SerializableAttribute()]

Answer 1

The solution was to ensure that at least one complex type inside of my WebService derived from a class or was a class which is abstract. Failure to have a class which is abstract causes the serializer to opt for System.Runtime.Serialization as the serialization engine of choice, but by including an abstract class it is forced to use System.ServiceModel.