Powershell: Error consuming WCF services with MTOM message encoding
I'm currently exploring powershell capabilities, but I have encountered a problem that I have not been able to solve. Any quick tips would be greatly appreciated =)
My goal: Invoke methods from a WCF service (configured with MTOM message encoding) from powershell v2.0 (hopefully using the new-webserviceproxy cmdlet)
My problem: the new-webserviceproxy cmdlet cannot parse the service's response correctly when message encoding is set to Mtom. I receive the following error:
PowerShell :
$proxyObject = New-WebServiceProxy -URI "http://myserver.com/AccessService.svc?wsdl"
$proxyObject.TestWebServiceConnection()
4001d529-32b9-4560-9f4b-550c35c67b03+id=4";start-info="text/xml"', but expected 'text/xml'.
The request failed with the error message:
--
--uuid:4001d529-32b9-4560-9f4b-550c35c67b03+id=4
Content-ID: <http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<TestWebServiceConnectionResponse xmlns="http://myserver.com/">
<TestWebServiceConnectionResult>success</TestWebServiceConnectionResult>
</TestWebServiceConnectionResponse>
</s:Body>
</s:Envelope>
--uuid:4001d529-32b9-4560-9f4b-550c35c67b03+id=4--
--."
At line:1 char:38
+ $proxyObject.TestWebServiceConnection <<<< () >> error.txt
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : DotNetMethodException
Note I am able to consume the WCF service through other clients and even the wcfclient tool provided by Microsoft. You can see that the TestWebServiceConnectionResult returned success, but it doesn't seem like the proxy object was able to parse the response.
Behavior :
<serviceBehaviors><behavior name="MyServiceBehavior">
<serviceThrottling maxConcurrentCalls="100" maxConcurrentSessions="100"/>
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="false"/>
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
Binding (I've excluded the timeout values/ reader quota and message sizes since the permutations of their values do seem not relevant to my problem):
<basicHttpBinding>
<binding name="basicHttpEndpointBinding" messageEncoding="Mtom">
<security mode="None">
<transport clientCredentialType="None"/>
</security>
</basicHttpBinding>
Service
<service behaviorConfiguration="MyServiceBehavior" name="MyService.AccessService"><endpoint address="" binding="basicHttpBinding" bindingConfiguration="basicHttpEndpointBinding" name="basicHttpEndpointAccessService" bindingNamespace="http://myserver.com/" contract="MyService.IAccessService"/>
<endpoint address="mex" binding="basicHttpBinding" bindingConfiguration="basicHttpEndpointBinding" name="mexEndpointAccess" contract="IMetadataExchange"/>
</service>
As of the time of this writing, I still have not been able to successfully use the New-WebServiceProxy cmdlet with a WCF service with MTOM enabled; it does not look like the cmdlet supports it. My workaround involved running svcutil.exe against the wsdl, and then compiling the class into a dll using csc.exe . I then loaded the generated assembly into the powershell run time, and then configured the endpoint and binding of the proxy class manually:
Generating the .cs file from your wsdl:
$svcUri = "http://yourdomain/yourService.svc?wsdl";
$csFile = $className + '.cs'; # The name of the generated .cs file
$dllName = [System.IO.Path]::Combine($temp, $className + ".dll")
$svcUtilresult = svcutil.exe /noConfig /out:$csFile $svcUri
Note svcutil.exe and csc.exe may not be in your powershell's PATH. You can either add it to your PATH or use the full path. Svcutil can be found within your Microsoft SDKsWindows<version>bin . csc.exe is located in your %windir%Microsoft .Net folder
Once you have generated the .cs file, you will need to compile it into a dll:
&"csc.exe" /t:library /out:$dllName $csFile
Load the compiled dll into powershell:
$fileStream = ([System.IO.FileInfo] (Get-Item ".$dllName")).OpenRead()
$dllBytes = new-object byte[] $fileStream.Length
$fileStream.Read($dllBytes, 0, $fileStream.Length)
$fileStream.Close()
[System.Reflection.Assembly]::Load($dllBytes)
Instantiate the proxy client in powershell:
# Load System.ServiceModel, which can be found in your Frameworkv3.0Windows Communication Foundation folder
[System.Reflection.Assembly]::LoadFile($pathToSystemServiceModel)
# className is the name of your service
$serviceClientName = $className + "Client"
$basicHttpBinding = New-Object System.ServiceModel.BasicHttpBinding
$basicHttpBinding.MessageEncoding = [System.ServiceModel.WSMessageEncoding]::Mtom
$endPoint = New-Object System.ServiceModel.EndpointAddress($svcUri)
$wsClient = New-Object $serviceClientname($basicHttpBinding, $endPoint)
I was having a similar problem. However I happened to already have the ClientBase generated code compiled into a local assembly.
My solution was:
add-type -path "....binMYassemblyWithWCFCLient.dll"
$binding = new-object system.servicemodel.basichttpbinding
$binding.MessageEncoding = "Mtom"
$endpoint = new-object System.ServiceModel.EndpointAddress("http://whodunit.oops/mtomandjerry.svc")
$regProxy = new-object MySpecialNamespace.OopsServiceContractClient($binding, $endpoint)