Today I was working on installing a WCF application on Windows Server 2008, hosted by IIS 7. This was my first attempt at running WCF on IIS 7/Server 2008, and the first time WCF was used on this particular box. Needless to say, things didn’t work as expected.
Since this is a test box, I didn’t have a public cert for use with SSL, but IIS 7 adds a very nice Self Signing Cert feature, which is accessible in the IIS Manager under the root server node (look for server certificates under IIS). Unfortunately, the self signed cert uses the computers fully qualified host name, and you are not given an option to fix this. Looking around, it looks like the self signing cert tool that shipped with the IIS 6 resource kit allowed you to specify the domain name. Anyway, this is a minor inconvenience, and easily fixed by using the windows hosts file to redirect. You need to remember to export the cert from the IIS management tool, and import it to your trusted root certs on any client computer to avoid getting warnings in IE, and errors in your WCF client applications.
However, certs were not the reason for this post, the following error was:
Error the client and server are no longer in sync for their wcf service settings. System.ServiceModel.ProtocolException: The remote server returned an unexpected response: (405) Method Not Allowed. ---> System.Net.WebException: The remote server returned an error: (405) Method Not Allowed. at System.Net.HttpWebRequest.GetResponse() at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout) --- End of inner exception stack trace --- Server stack trace: at System.ServiceModel.Channels.HttpChannelUtilities.ValidateRequestReplyResponse(HttpWebRequest request, HttpWebResponse response, HttpChannelFactory factory, WebException responseException) at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout) at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout) at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout) at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs) at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message) Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at …
Looking back at this error, I think I may have missed a key clue. The phrase “The remote server returned an unexpected response” should have clued me in that something wasn’t setup right. I usually see this type of error when IIS tries to display an error message in HTML, thinking that it’s a browser request. The WCF client application isn’t expecting HTML, so it throws an error.
It’s been awhile since I worked with WCF, and I forgot basic trouble shooting 101 for a couple of minutes, and finally remembered to just type in the URL to the .svc file on the server. I was greeted with an IIS 7 error page that listed some pretty good trouble shooting steps. The first one said to check the server handler mappings, which I did, and noticed there were not mappings for .svc. I found a blog post on wcf and silverlight, which explained how to enable WCF on IIS 7.
Now I had installed WCF (.net 3.0) via the features section of server manger in Server 2008, but I guess that doesn’t actually enable it to work with IIS 7. Maybe I didn’t install something in the correct order. Fair enough, and the fix is simple. From a command prompt (I ran mine with admin privileges under UAC), execute ServiceModelreg -i in c:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation. Once this was done, I went back to my handler mappings and saw entries for .svc.
I’d like to note that the error messages returned by IIS 7 in the browser window (when browsing from the web server itself), gives allot better error and diagnostics information for trouble shooting.