This is a problem I have tripped across before, and it just popped up again. Time for a post on how to fix it, mainly so I won’t have to track down MSDN articles and obscure posts to remember how to do it!
When building a WCF Web Service on your local machine, the service will automatically generate WSDL for you with an address similar to http://YOURPC/MyService.svc. This works fine when testing locally, but when you want to publish this to your production environment so it can be used by World + Dog, it doesn’t respect the fact you have a nice URL you would like to use instead. For example, if your production server is “Server01″ and the URL you have assigned to the website in IIS is my.publicserver.com, your service may look like this:
Instead of displaying the “real” URL (my.publicserver.com), it displays the name of the server (server01) instead. Not at all what is required! Worse still, connections to your web server will fail because the WSDL is pointing to the non-published server name and your client won’t be able to get there. This is because WCF automatically uses the IIS Site Bindings to determine what the base addresses for the service should be.
The solution is to update the IIS metabase so IIS knows what to do with the request, then WCF will pick up on this. To fix this, perform the following steps.
Get the Website Identifier from IIS
To change the site bindings you need to know which site to change. Open the IIS Manager to view the sites available, find the one you want to change, and record the website id in the “Identifier” column. You will need this in the next step.
Change the IIS Site Bindings
The format of an IIS site binding is “<ip>:<port>:<hostname>”. For HTTP, the default site binding for the default web site is “:80:”. The service gets messages from any IP addresses for the host and it uses “weak” wildcard for address registration. It needs to be the same as the same host name for the site so that it shows up in your service base address. The IIS utility tool adsutil.vbs (or appcmd.exe on IIS7) is used to modify the IIS metabase entries.
View your current site bindings using the example below.
NOTE – YOU MUST USE YOUR WEBSITE IDENTIFIER.
cscript.exe //NoLogo %systemdrive%\inetpub\adminscripts\adsutil.vbs get W3SVC/your_website_identifier_here/ServerBindings
and, for SSL/secure connections, use the following to view the current site bindings:
cscript.exe //NoLogo %systemdrive%\inetpub\adminscripts\adsutil.vbs get W3SVC/your_website_identifier_here/SecureBindings
To change the site bindings, modify the “get” to a “set” and put in your domain name to link to as per the following example:
cscript.exe //nologo %systemdrive%\inetpub\adminscripts\adsutil.vbs set W3SVC/your_website_identifier_here/ServerBindings “:80:my.publicserver.com”
cscript.exe //nologo %systemdrive%\inetpub\adminscripts\adsutil.vbs set W3SVC/your_website_identifier_here/SecureBindings “:443:my.publicserver.com”
Reset the App Pool
When the IIS settings have been changed, WCF will not automatically pick up the changes from the IIS Metabase until the AppDomain has been restarted. Do this via:
Changing/resaving the web.config file for the virtual application (you don’t need to actually change the file, as long as it is saved so .NET picks up the change and restarts the app domain)
Restart the server
This should complete the changes. When you query the WCF service again, the base address should be correct.