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)
