When exposing a WCF service and hosting it on IIS6, most probably you are going to get the error shown in the image below, where the address of the WSDL location is not properly exposed to the end clients.
As the following WSDL gets created (shown in the picture below), the consequence of this is that de-facto you are not able to expose your service to your clients without manually sending them the WSDL and correcting the location of the schema for the exposed types.
How to fix this?
Mainly, there are two ways of fixing this:
- Changing the web.config file (works only for .NET 4 and above)
- Tweaking the IIS for version of .NET 3 and 3.5
Web Config change
web.config would work only for the .NET v4 and above, as Microsoft introduced a fix for this.
You should simply add the
part as part of your
serviceBehaviors/behavior and magically this is going to work.
<behaviors> <serviceBehaviors> <behavior name="name of your behaviour"> <useRequestHeadersForMetadataAddress> <defaultPorts> <add scheme="https" port="443" /> </defaultPorts> </useRequestHeadersForMetadataAddress> </behavior> </serviceBehaviors> <behaviors>
The reason this problem happens in IIS 6 is because IIS 6 doesn’t expose the header name for the TSL/SSL (https) based web sites and therefore WCF is (was) not aware of the header that the web site where the WCF is hosted, responds to.
In order to fix this, you should run the admin script to change your web site bindings, as this cannot be done anywhere else in the IIS Admin gui.
Script that changes the IIS binding:
cscript.exe //nologo %systemdrive%\inetpub\adminscripts\adsutil.vbs set W3SVC/
To check if this really worked, change the set to get:
cscript.exe //nologo %systemdrive%\inetpub\adminscripts\adsutil.vbs get W3SVC/
I really hope that this info will be on your help as made me and my team spend quite a lot of time into finding out the solution. In our case the .NET 4 saved us from modifying directly the IIS bindings.