This is the eighth post in the WCF 4.5 series. This post continues the previous posts on web-hosting features. This post is about the ASP.NET compatibility mode default change of WCF 4.5.
Normally, a WCF service hosted under IIS works side-by-side with ASP.NET – they share some of the pipeline, they have the same application domain, but work quite independently of each other when it comes to the HTTP context (authorization, context, session, etc…). This is the default behavior of WCF.
However, you can change the default behavior of WCF and set it to ASP.NET compatibility mode – this allows WCF and ASP.NET to share most of the pipeline, and have the same HTTP context. This has some advantages and some disadvantages (such as the problem of ASP.NET sessions and blocking WCF calls).
To make WCF use the ASP.NET compatibility mode you need to do the following two changes:
1. Enable ASP.NET compatibility mode for the hosting environment in your web.config:
<serviceHostingEnvironment aspNetCompatibilityEnabled=”true” />
2. Set each of your services to support the compatibility mode, by adding the AspNetCompatibilityRequirements attribute.
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
You can read more about WCF and ASP.NET on MSDN.
So what has changed in WCF 4.5?
In WCF 4.5 the default behavior of WCF is to support the ASP.NET compatibility mode automatically. This is achieved by the following changes:
1. In the WCF Service Application project template, the aspNetCompatibilityEnabled attribute was added to the serviceHostingEnvironment element, and it is set to true by default.
2. The default value of the AspNetCompatibilityRequirements attribute has changed from NotAllowed to Allowed. Without this changed default, you would have needed to manually add the attribute to every new service. This is noticeable in the attribute’s documentation:
ASP.NET compatibility mode is very useful if you need to use share information between your ASP.NET application and WCF service in regards to the HTTP context, session, or user authorization, but be careful of the concurrency problem that occurs when sharing session state between WCF and ASP.NET.
Expect more on ASP.NET and WCF in next posts, so stay tuned. You can also follow me on Twitter (@IdoFlatow) to get updates as soon as new posts are published.
The RTM of .NET 4.5 is still to come, and I assume many of you are still adjusting to WCF 4. If you want to learn more about the new features of WCF 4, come to my session at Visual Studio Live! 2011 in Orlando (December 5-9).