February 20, 2012 Leave a comment
A few days ago I published a short post on controlling the locale for Windows Azure Applications, turns out that a significant piece was missing – whilst all that was written was well and true for web applications, the story for WCF services is slightly different –
By default web services do not run in ASP.net compatibility mode, and without this, many system.web settings in the web.config do not take effect, the MSDN article Hosting and Consuming WCF Services contains the following paragraph (bold is mine) –
ASP.NET Compatibility Model
When hosting your WCF services in a load-balanced or even a Web-garden environment where subsequent requests in a session can be processed by different hosts or processes in the environment, you need out-of-process persistent storage for your session state. Out-of-the box WCF doesn’t support persistent storage for session state. Instead, WCF stores all its session state in memory. When your WCF services are hosted in IIS, you can end up with recycling scenarios, as described in the previous section. Instead of building persistent storage for sessions all over again, WCF relies on the ASP.NET implementation for session state. This approach has one serious limitation: you limit your services to HTTP.
ASP.NET session state is not the only feature that is supported by the ASP.NET compatibility mode. It also supports features such as the HttpContext, globalization, and impersonation, just like you are used to with ASP.NET Web services (ASMX). Refer to MSDN Help for the ASP.NET–specific features to enable out-of-process session state.
And so – if you wanted to use the <globalization> element to control the locale of WCF service you must ensure your services are running in ASP.net compatibility mode, as shown in the MSDN article, this can be done by adding the following attribute to the service implementation –
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)] public class Service1 : IService1
But to allow that you would also need to add the following entry to the web config –
<system.serviceModel> <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
If you’d rather not run in compatibility mode, an alternative is to set the thread’s UI culture, as shown in my previous post, in the service’s constructor.
Note: for completeness I should add that this applies to WebServiceHost and REST services as much as it does for ServiceHost and SOAP based services, I have tested both.