Hosting WCF Services
Generating proxies
Out of the box, using
Add Service Reference or
svcutil to generate a proxy to a service hosted either in the development fabric or the cloud fabric will fail with an error similar to
The document at the url http://127.0.0.1:83/ConsoleCalculator/Service.svc was not recognized as a known document type.
The error message from each known type may help you fix the problem:
- Report from 'http://127.0.0.1:83/ConsoleCalculator/Service.svc' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
- Report from 'DISCO Document' is 'There was an error downloading 'http://machinename:5107/ConsoleCalculator/Service.svc?disco'.'.
- The request failed with HTTP status 400: Bad Request.
- Report from 'XML Schema' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
- Report from 'WSDL Document' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
Metadata contains a reference that cannot be resolved: 'http://127.0.0.1:83/ConsoleCalculator/Service.svc'.
There was no endpoint listening at http://127.0.0.1:83/ConsoleCalculator/Service.svc that could accept the message. This is
often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
The remote server returned an error: (404) Not Found.
If the service is defined in the current solution, try building the solution and adding the service reference again.
To fix this, ensure that the following line is added to the
<system.serviceModel> section of your Web.config:
<system.serviceModel>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
<!-- other elements -->
</system.serviceModel>
If a service is available over both HTTP and HTTPS, ensure that metadata is available over both, otherwise you still might get the above error when using the HTTPS endpoint.
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
<!-- other behaviors -->
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
If your WebRole is running in .Net 3.5, you need to install the following QFE and add a behavior as shown below. If your WebRole is using .Net 4.0, you can skip over this part. Define the following service behavior in your Web.config file. Don't forget to reference the behavior you just created from your service by setting
<service behaviorConfiguration="LoadBalancedBehavior" /> when you declare your service.
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="LoadBalancedBehavior">
<serviceMetadata httpGetEnabled="true" />
<useRequestHeadersForMetadataAddress>
<defaultPorts>
<add scheme="http" port="81" />
<add scheme="https" port="444" />
</defaultPorts>
</useRequestHeadersForMetadataAddress>
<!-- Other service behaviors as necesary -->
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
When using Visual Studio 2008 this configuration section might get underlined as incorrect in the .config IntelliSense, but that can sefely ignored as long as the service runs correctly.
Address filter mismatch
At runtime, WCF services may return the following error:
The message with To 'http://127.0.0.1:81/Service.svc' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree.
The error happens if you try to use bindings that require WS-Addressing. BasicHttpBinding does not exhibit the error. The error can be corrected by using
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" /> as shown above.
If your WebRole is running in .Net 3.5, the above workaround will not work. If your WebRole is using .Net 4.0, you can skip over this part. Add the following attribute to your service class.
[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
Standard endpoints
In .Net 4, WCF provides a new configuration simplification feature called
standard endpoints. If you define a a standard endpoint, the WebRole gets stuck in the busy state.
The issue can be fixed by adding the following section to your Web.config:
<configSections>
<sectionGroup name="system.serviceModel" type="System.ServiceModel.Configuration.ServiceModelSectionGroup, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="standardEndpoints" type="System.ServiceModel.Configuration.StandardEndpointsSection, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</sectionGroup>
</configSections>
This issue will be addressed in the next Azure release and the workaround will no longer be necessary.
Partial trust
Only a subset of WCF functionality is supported in partially-trusted hosting environments such as Azure fabric. Here is a
list of WCF features supported in partial trust. In order to access features that require full trust in the Azure fabric, your role needs to specifically opt in to full trust, as described in
this blog post from the Azure team. Turning on full trust significantly increases the set of WCF features supported in Azure.
Hosting WCF REST Services
By default, WCF REST services may experience issues around the base address they are hosted on. These issues may affect features such as UriTemplates and the WCF help page feature. The fix mentioned above, which involves using
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" /> will address these issues when running WebRoles based on .Net 4.0.
Hosting Silverilght Clients
Registering MIME type in development fabric
To ensure solutions containing Silverlight clients work correctly in the development fabric, please ensure that the MIME type for the Silverlight .xap extension is configured correctly in IIS.
- Open Internet Information Services (IIS) Configuration Manager and select the server to manage (usually the top-level item on the left side)
- Double-click MIME Types on the right side
- Add an entry to map the .xap extension to the application/x-silverlight-app MIME type
Specifying a relative service address
Normally when adding a service reference, Silverlight will generate a .clientConfig file containing the address of the service. This config file gets pacakged as part of the Azure service and cannot be edited as the service moves from the development fabric, to staging in the cloud fabric, to production in the cloud fabric. This poses a problem since the hardcoded service address will change between these three locations.
To use a
relative address, you can use a relative address in your .clientConfig file, as described in
this document. Provided the Silverlight XAP package is hosted at http://wcfazure.cloudapp.net/application/ClientBin/Application.xap, the following addresses resolve as indicated:
- "../Service1.svc" resolves to http://wcfazure.cloudapp.net/application/Service1.svc
- "Service1.svc" resolves to http://wcfazure.cloudapp.net/application/ClientBin/Service1.svc
- "/Service1.svc" resolves to http://wcfazure.cloudapp.net/Service1.svc
Multiple instances of duplex services using PollingDuplexHttpBinding
Silverlight provides out of the box support for pushing data from the WCF server to the Silverlight client, to enable scenarios such as stock tickers and chat clients. This approach is described in
this documentation topic. A limitation exists when hosting services using PollingDuplexHttpBinding in Azure. If a single instance of a duplex service is hosted in Azure, everything works as expected.
If multiple instances of a service are hosted, the Azure load balancer will arbitrarily route traffic to these instances. This poses a problem since each duplex service maintains an internal state table of all the connected client sessions. A session might exist between a Silverlight client and a given duplex service, but messages might get routed to another duplex service instance that has never talked to this client before.
The work-around for this issue is to provide the ability in PollingDuplexHttpBinding to store the state table in a centralized location that can be accessed by multiple services. Some initial investigation has been done in this area and
a code sample is available, which allows you to manage the PollingDuplex session state yourself. A further sample is forthcoming, which will illustrate how to store that session state in Azure storage.