New-WebServiceProxy additional [ref] parameters?


I am trying to utilize a SOAP service using New-WebServiceProxy but somehow I have a strange behavior that Powershell is adding elements that are part of the output message to the input message arguments.
The code I am executing is:

$uri = ''
$proxy = New-WebServiceProxy -Uri $uri

In the XML a GetList operation is defined with following values

As you can see it take 3 parameters and if I call it from other tools (SOAPUI or Wizdler) it is properly working. However if look at the $proxy.getlist value it shows me following:


string GetList(string Qualification, string startRecord, string maxLimit, [ref] string Submitter__c, [ref] datetime Create_Date__c, [ref] bool Create_Date__cSpecified, [ref] string
Assigned_To__c, [ref] string Last_Modified_By__c, [ref] datetime Modified_Date__c, [ref] bool Modified_Date__cSpecified, [ref] …
(continuing list of 50+ parameters)

The [ref] arguments are actually elements defined in the response message:


If I try to call the operation with only 3 arguments I receive an error:
Cannot find an overload for “GetList” and the argument count: “3”.

I have tested it with Powershell 5.1 and 4.0, same behavior.
Can anyone tell me why Powershell adds these [ref] arguments? It clearly is working with other tools so the XML itself seems to be fine.

Thank you.

You’re going to need to use a Gist as indicated in the posting instructions. Raw XML can’t render here.

Thank you. I noticed it too late and could not edit the post anymore because it was already pending for review.
To complete the post:

In the XML a input message is defined as:

And the output message is defined as:

I would expect that I can invoke the GetList call with 3 parameters (Qualification, startRecord, maxLimit) but as mentioned in my initial post Powershell returns an error. It seems to expects also values for the [ref] arguments (Submitter__c, Create_Date__c, Assigned_To__c,…) that are actually defined in the response message.

Any idea?

Solved in the meantime. At the end it turned out to be caused by the SOAP XML created by the application. So if someone faces a similar issue, first thing check your XML. however, I still don’t know what exactly caused the problem. I also had the XML checked by an online validation tool which showed me that the file was generally valid - so you can’t rely on that.

But it is still wired that Powershell behaves in such unexpected way when other solutions like SOAPUI and Wizdler had no problem with it.