Author Posts

August 23, 2017 at 7:25 am


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.

August 23, 2017 at 1:00 pm

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

August 28, 2017 at 2:03 am

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?

September 12, 2017 at 2:33 am

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.