WcfTestClient with Windows Azure
One of my customers is working on an Azure WCF service. When wanted to test the service with WcfTestClient, but we ran into some issues. We started the dev fabric and had the WebRole running on port 81. When we went to the WCF service metadata page at http://mybox:5101/ProdKService.svc, we got the expected web page, which states:
To test this service, you will need to create a client and use it to call the service. You can do this using the svcutil.exe tool from the command line with the following syntax:
svcutil.exe http://mybox:5101/ProdKService.svc?wsdl
This will generate a configuration file and a code file that contains the client class. Add the two files to your client application and use the generated client class to call the Service.
Note that the instructions point you to port 5101 in the service URL. That’s the port where the Azure instance is running in my local development fabric. It is not as we would expect the address of the Azure dev fabric which is running on port 81. We tried to follow the instructions and point WcfTestClient to the address on the page, but instead of testing the service, we got this not so friendly error message:
Error: Cannot obtain Metadata from http://mybox:5101/ProdKService.svc If this is a Windows (R) Communication Foundation service to which you have access, please check that you have enabled metadata publishing at the specified address. For help enabling metadata publishing, please refer to the MSDN documentation at http://go.microsoft.com/fwlink/?LinkId=65455.WS-Metadata Exchange Error URI: http://mybox:5101/ProdKService.svc Metadata contains a reference that cannot be resolved: 'http://mybox:5101/ProdKService.svc'. There was no endpoint listening at http://mybox:5101/ProdKService.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. The remote server returned an error: (400) Bad Request.HTTP GET Error URI: http://mybox:5101/ProdKService.svc There was an error downloading 'http://mybox:5101/ProdKService.svc'. The request failed with HTTP status 400: Bad Request.
Now this is weird. We know that metadata publishing is enabled, because we got the instructions for the WSDL address from the metadata page in the first place.
If you look at the address line in the browser when the Azure dev fabric launches, you note that the local fabric is listening on localhost port 81, not mybox port 5101. localhost is IP address 127.0.0.1, whereas mybox is bound to the IP address on my corporate network. . Is instructed, we tried to get the WSDL with http://127.0.0.1:81/ProdKService.svc?wsdl and we’re getting a different error in in WcfTestClient:
Error: Cannot obtain Metadata from http://mybox:5101/ProdKService.svc If this is a Windows (R) Communication Foundation service to which you have access, please check that you have enabled metadata publishing at the specified address. For help enabling metadata publishing, please refer to the MSDN documentation at http://go.microsoft.com/fwlink/?LinkId=65455.WS-Metadata Exchange Error URI: http://mybox:5101/ProdKService.svc Metadata contains a reference that cannot be resolved: 'http://mybox:5101/ProdKService.svc'. Could not connect to http://mybox:5101/ProdKService.svc. TCP error code 10061: No connection could be made because the target machine actively refused it 127.0.0.1:5101. Unable to connect to the remote server No connection could be made because the target machine actively refused it 127.0.0.1:5101HTTP GET Error URI: http://mybox:5101/ProdKService.svc There was an error downloading 'http://mybox:5101/ProdKService.svc'. Unable to connect to the remote server No connection could be made because the target machine actively refused it 127.0.0.1:5101
It took a little bit to figure this one out since the error message is so similar to the first one. The difference is only in the InnerException and you have to look at the WSDL at http://mybox:5101/ProdKService.svc?wsdlto understand the error.
The culprit for this error is the schemaLocation reference in the WSDL:
<xsd:import schemaLocation="http://mybox:5101/ProdKService.svc?xsd=xsd0" namespace="http://tempuri.org/" />
Even though we retrieved the WSDL from the localhost address, the WSDL generator in WCF generates a reference to the other network address.
Since there’s no easy way to configure the Metadata generator in WCF to switch the hostname for the schemaLocation, I added the hostname to my C:\Windows\System32\drivers\etc\hosts
127.0.0.1 mybox
After restarting the Azure dev fabric, WcfTestClient was able to read the MEX metadata for the service.
I also tried another work-around since not everybody modifying the hosts file may not be possible (although you also need admin rights for running the dev fabric). There is still Christian’s old FlatWsdl trick.
Adding the FlatWsdl extension and configuring the ServiceHost Factory in the Services’ s .svc file got WcfTestClient to work, too.