Lighter Configuration Files and Better ASP.NET Support with WCF 4.5
Ido Flatow has been posting a series on the upcoming changes to WCF in .NET 4.5.
In the category of noise reduction, WCF’s automatically generated configuration files will be much, much smaller. Since the first version of WCF, developers found themselves maintaining an app.config file with close to 30 settings which are in fact just the default values. Those who know better delete the extraneous settings, but unfortunately many never learned that trick. With WCF 4.5 the config file will default to just the binding type and name.
Of course this leads to the next training question, “How do I know what the settings are?” To answer that we will also be getting tooltips and code-completion in the configuration files. This will not be just schema-based hints; if you are configuring an endpoint and need the name of a behavior or configuration it will be smart enough to list them for you. This even includes support for compiler warnings if the configuration, contract type, or behavior name is misspelled.
For those who work directly with WSDL, there is good news for you as well. WCF 4.5 will now return a complete WSDL in a single request. Previously it would only include a partial WSDL that was required fetching a series of matching XSD files. To take advantage of this option use the ?singleWsdl query string instead of ?singleWsdl.
While hosting WCF inside a Windows Service is perfectly acceptable, most developers continue to leverage IIS for the bulk of their work. And why not, it offers built-in support for features such as authentication, state management, and process recycling. But there are some limitation in this model that Microsoft is still working through. For example, currently one has to configure which authentication modes were supported in two places. If they accidentally get out of sync then the service simply stops working. WCF 4.5 removes this particular class of bugs by allowing the service to defer to IIS by setting the authentication type to “InheritedFromHost”.
Unfortunately this is only a partial fix. If IIS happens to have multiple authentication types enabled then the clients will only acknowledge the first one. Client developers can override this to use another type, assuming of course they find out about the option another way. Please note this is entirely a client-side tooling problem, the WSDL file is listing all of the options.
A bug that is expressed in the WSDL is the construction of URIs for HTTPS service ports. As of .NET 4.0, WCF had the option to automatically generate ports for each type of binding (HTTP, TCP, etc.). Unfortunately HTTPS wasn’t included at that time, an oversight that will be corrected in .NET 4.5. Ido Flatow reports that the HTTPS version is advertising the machine name instead of host name used to request the WSDL. This can be a problem when using a web farm.
Another bug is the way WCF works with streaming data. According to Ido,
When you host a WCF service in IIS you also get a bit of the ASP.NET pipeline on the side, even if you don’t use the ASP.NET compatibility mode, this is documented in the WCF Services and ASP.NET article on MSDN (look for the part about the PostAuthenticateRequest event). In .NET 4, there is a design flaw in ASP.NET which causes the requests sent to WCF to be buffered in ASP.NET. This buffering behavior causes several major side-effects:
Not only does this put a delay into the processing of request, particularly large content can even start spilling onto the hard drive. This has been corrected in WCF 4.5