I have come across 2 issues with deploying WCF services in a Silverlight solution, admittedly the one is more of a hiccup, and only occurs if you take the easy way out and reference your services through visual studio.

The First Issue

This occurs when you deploy your WFC services to an IIS server. When browse to the services using your web browser, you are greeted with “This collection already contains an address with scheme http.  There can be at most one address per scheme in this collection.”. When you make a call to this service from your Silverlight application, you get the extremely helpful “NotFound” error, this error message can be found in the error property of the event arguments on the complete event handler for that call.

As it did with me this will leave most people scratching their head, because the very same services work just fine on the ASP.NET Development Web Server and on my local IIS server. Now I’m no server/hosting/IIS expert so I did a bit of searching when I first encountered this issue. I found out this happens because IIS supports multiple address bindings per protocol (http/https/ftp … etc) per web site, but WCF only supports binding to one address per protocol. This causes a problem when the WCF service is hosted on a site with multiple address bindings, because IIS provides all of the bindings to the host factory when running the service. While this problem occurs mainly on shared hosting solutions, it is not limited to shared hosting, it just seems like all shared hosting providers setup sites on their servers with multiple address bindings.

For interests sake I added functionality to the example project attached to this post to dump the addresses given to the WCF service by IIS into a log file. This was the output on the shared hosting solution I use:

http://mydomain.co.za/Services/TestService.svc
http://www.mydomain.co.za/Services/TestService.svc
http://mydomain-co-za.win13.wadns.net/Services/TestService.svc
http://win13/Services/TestService.svc

As you can see all these addresses are for the http protocol, which is where it all goes wrong for WCF.

Fixes for the First Issue

There are a few ways to get around this. The first being the easiest, target .NET 4! Yes that's right in .NET 4 WCF services support multiple addresses per protocol. This functionality is enabled by an option, which is on by default if you create a new project, you will need to turn on if you are upgrading to .NET 4. To do this set the multipleSiteBindingsEnabled property of the serviceHostingEnviroment tag in the web.config file to true, as shown below:

<system.serviceModel>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>

Beware this ONLY works in .NET 4, so if you don’t have a server with .NET 4 installed on that you can deploy to, you will need to employ one of the other work a rounds.

The second option will work for .NET 3.5 & 4. For this option all you need to do is modify the web.config file and add baseAddressPrefixFilters to the serviceHostingEnviroment tag as shown below:

<system.serviceModel>
    <serviceHostingEnvironment>
        <baseAddressPrefixFilters> 
            <add prefix="http://www.mydomain.co.za"/>
        </baseAddressPrefixFilters>
    </serviceHostingEnvironment>
</system.serviceModel>

These will be used to filter the list of base addresses that IIS provides to the host factory. When specifying these prefix filters be sure to specify filters which will only allow 1 result through, otherwise the entire exercise will be pointless. There is however a problem with this work a round, you are only allowed to specify 1 prefix filter per protocol. Which means you can’t add filters for all your environments, this will therefore add to the list of things to do before deploying or switching dev machines.

The third option is the one I currently employ, it will work for .NET 3, 3.5 & 4, although it is not needed for .NET 4. For this option you create a custom host factory which inherits from the ServiceHostFactory class. In the implementation of the ServiceHostFactory you employ logic to figure out which of the base addresses, that are give by IIS, to use when creating the service host. The logic you use to do this is completely up to you, I have seen quite a few solutions that simply statically reference an index from the list of base addresses, this works for most situations but falls short in others. For instance, if the order of the base addresses where to change, it might end up returning an address that only resolves on the servers local network, like the last one in the example I gave at the beginning. Another instance, if a request comes in on a different protocol, like https, you will be creating the service host using an address which is on the incorrect protocol, like http.

To reliably find the correct address to use, I use the address that the service was requested on. To accomplish this I use the HttpContext, which requires the service to operate with AspNetCompatibilityRequirements set on. If for some reason running you services with AspNetCompatibilityRequirements on isn’t an option, you can still use this method, you will just have to come up with your own logic for selecting the correct address.

First you will need to enable AspNetCompatibilityRequirements for your hosting environment, to do this you will need to set it to true in the web.config file as shown below:

<system.serviceModel>
    <serviceHostingEnvironment AspNetCompatibilityRequirements="true" />
</system.serviceModel>

You will then need to mark any services that are going to use the custom host factory, to allow AspNetCompatibilityRequirements, as shown below:

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class TestService
{
}

Now for the custom host factory, this is where the logic lives that selects the correct address to create service host with. The one i use is shown below:

public class CustomHostFactory : ServiceHostFactory
{
    protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
    {
        //
        // Compose a prefix filter based on the requested uri
        //
        string prefixFilter = HttpContext.Current.Request.Url.Scheme + "://" + HttpContext.Current.Request.Url.DnsSafeHost;
        if (!HttpContext.Current.Request.Url.IsDefaultPort)
        {
            prefixFilter += ":" + HttpContext.Current.Request.Url.Port.ToString() + "/";
        }

        //
        // Find a base address that matches the prefix filter
        //
        foreach (Uri baseAddress in baseAddresses)
        {
            if (baseAddress.OriginalString.StartsWith(prefixFilter))
            {
                return new ServiceHost(serviceType, baseAddress);
            }
        }

        //
        // Throw exception if no matching base address was found
        //
        throw new Exception("Custom Host Factory: No base address matching '" + prefixFilter + "' was found.");
    }
}

The most important line in the custom host factory is the one that returns a new service host. This has to return a service host that specifies only one base address per protocol. Since I filter by the address the request came on in, I only need to create the service host with one address, since this address will always be of the correct protocol.

Now you have a custom host factory you have to tell your services to use it. To do this you view the markup of the service by right clicking on it in the solution explorer and choosing “View Markup”.

Then you add/set the value of the Factory property to the full namespace path of you custom host factory, as shown below.

And that is it done, the service will now use the specified custom host factory.

The Second Issue

As I mentioned earlier this issue is more of a hiccup, but I thought worthy of a mention so I included it. This issue only occurs when you add a service reference to a Silverlight project. Visual Studio will generate a lot of code for you, part of that generated code is the ServiceReferences.ClientConfig file. This file stores the endpoint configuration that is used when accessing your services using the generated proxy classes. Here is what that file looks like:

<configuration>
    <system.serviceModel>
        <bindings>
            <customBinding>
                <binding name="CustomBinding_TestService">
                    <binaryMessageEncoding />
                    <httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
                </binding>
                <binding name="CustomBinding_BrokenService">
                    <binaryMessageEncoding />
                    <httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
                </binding>
            </customBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:49347/services/TestService.svc"
                binding="customBinding" bindingConfiguration="CustomBinding_TestService"
                contract="TestService.TestService" name="CustomBinding_TestService" />
            <endpoint address="http://localhost:49347/Services/BrokenService.svc"
                binding="customBinding" bindingConfiguration="CustomBinding_BrokenService"
                contract="BrokenService.BrokenService" name="CustomBinding_BrokenService" />
        </client>
    </system.serviceModel>
</configuration>

As you will notice the addresses for the end points are set to the addresses of the services you added the service references from, so unless you are adding the service references from your live services, you will have to change these addresses before you deploy. This is little more than an annoyance really, but it adds to the list of things to do before you can deploy, and if left unchecked that list can get out of control.

Fix for the Second Issue

The way you would usually access a service added this way is to create an instance of the proxy class like so:

BrokenServiceClient proxy = new BrokenServiceClient();

Closer inspection of these generated proxy classes reveals that there are a few overloaded constructors, one of which allows you to specify the end point address to use when creating the proxy. From here all you have to do is come up with some logic that will provide you with the relative path to your services. Since my WCF services are usually hosted in the same project as my Silverlight app I use the class shown below:

public class ServiceProxyHelper
{
    /// <summary>
    /// Create a broken service proxy
    /// </summary>
    /// <returns>A broken service proxy</returns>
    public static BrokenServiceClient CreateBrokenServiceProxy()
    {
        Uri address = new Uri(Application.Current.Host.Source, "../Services/BrokenService.svc");
        return new BrokenServiceClient("CustomBinding_BrokenService", address.AbsoluteUri);
    }
}

Then I will create an instance of the proxy class using my service helper class like so:

BrokenServiceClient proxy = ServiceProxyHelper.CreateBrokenServiceProxy();

The way this works is “Application.Current.Host.Source” will return the URL to the ClientBin folder the Silverlight app is hosted in, the “../Services/BrokenService.svc” is then used as the relative path to the service from the ClientBin folder, combined by the Uri object this gives me the URL to my service. The “CustomBinding_BrokenService” is a reference to the end point configuration in the ServiceReferences.ClientConfig file. Yes this means you still need the ServiceReferences.ClientConfig file. All this is doing is using a different end point address than the one specified in the ServiceReferences.ClientConfig file, all the other settings form the ServiceReferences.ClientConfig file are still used when creating the proxy.

I have uploaded an example project which covers the custom host factory solution from the first issue and everything from the second issue. I included the code to write a list of base addresses to a log file in my implementation of the custom host factory, this is not need for the custom host factory to function and can safely be removed.

Download (WCFServicesDeploymentExample.zip)