Additional information:
- Created a new cloud project with only a WCF role.
- Programmed two methods: Reset() and NextFibonacci(). So yes, the service calculates the Fibonacci sequence.
- Compiled.
- Edited web.config for the endpoints and such. They were there already.
- Ran the project.,
IE shows the help page when navigating to 127.0.0.1:81/Fibonacci.svc but strangely enough the link to the WSDL points to my full DNS computer name and port 82. The link doesn't work.
I also notice that the Azure Emulator shows http://*:81 in the deployment service details, and I also notice that IIS Express is running a website @ http://127.255.0.0:82 also pointing to the WCF root directory. So it looks as if the service was available
from either URL but none of the URL's work with the WCF Test Client.
When I try to connect to http://127.0.0.1:81/Fibonacci.svc I get the error:
Error: Cannot obtain Metadata from http://127.0.0.1:81/Fibonacci.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://127.0.0.1:81/Fibonacci.svc Metadata contains a reference that cannot be resolved: 'http://127.0.0.1:81/Fibonacci.svc'.
Content Type application/soap+xml; charset=utf-8 was not supported by service http://127.0.0.1:81/Fibonacci.svc. The client and service bindings may be mismatched. The remote server returned an error: (415)
Cannot process the message because the content type 'application/soap+xml; charset=utf-8' was not the expected type 'text/xml; charset=utf-8'..HTTP GET Error URI: http://127.0.0.1:81/Fibonacci.svc The document at the
url http://127.0.0.1:81/Fibonacci.svc was not recognized as a known document type.The error message from each known type may help you fix the problem:- Report from 'XML Schema' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.-
Report from 'http://127.0.0.1:81/Fibonacci.svc' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.- Report from 'DISCO Document' is 'There was an error downloading 'http://<my fully qualified workstation
name>:82/Fibonacci.svc?disco'.'. - Unable to connect to the remote server - No connection could be made because the target machine actively refused it 127.0.0.1:82- Report from 'WSDL Document' is 'The document format is not recognized
(the content type is 'text/html; charset=UTF-8').'.
Take a look at the bold part. I investigated and it seems that the service is being run for SOAP messages version 1.1 while the test client is sending a SOAP message v1.2. How did I get in this predicament? I honestly don't know. I
just installed the SDK June 2012. I had the November 2011 previously installed, but the newer installer did not complain.
If I use the WCF Test Client to connect to http://127.255.0.0:82/Fibonacci.svc then I get the treeview populated as if it worked OK. BUT: If I try to run NextFibonacci() it doesn't work and throsw and exception:
There was no endpoint listening at http://<my fully qualified workstation name>:82/Fibonacci.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
So at this point I am very confused. Why does the Azure debug environment seem to launch the website for the WCF service twice (one via the Windows Azure Compute Emulator and another through IIS Express), and when or how did I get into the SOAP version
mismatch?
To be honest this is very frustrating. At this rate I will never adopt or recommend Azure to anybody.
Jose R. MCP
Code Samples