What’s New in WCF 4: More on Services and Configuration

This list is a bit different in places from what you’ve seen in the beta 1 release and there’s always a chance that things might change again.

The third part of the list covers some of the new features for service configuration. I haven’t mentioned some of the larger changes for simplified configuration and standard endpoints because those are already a part of the official beta 1 list.

  • Short type name support: many of the configuration extensions require registering a CLR type for the extension object. We generally recommend using fully qualified type names, but this is not always practical during development. Several of the extension elements for WCF configuration now recognize and attempt to resolve short type names.
  • Location tag for service files: there is a standard ASP.NET configuration feature that allows a location element to describe configuration specific to a part of the application. With ASMX it was possible to use that location element with a path to the ASMX file. We’ve similarly enabled the use of location elements with SVC files.
  • Channel factories with custom configuration: we’ve added new channel factory subclasses that support passing in your own instance of a configuration object. This allows you to build configuration objects from a source other than the application configuration without having to construct the proxy objects entirely by hand.
Comments (2)

  1. tmanthey says:

    The weak point of WCF is in my opinion the client configuration.

    If you have a service function with growing volume over time, you will soon find out that WCF client configuration with hundreds of default quotas is in fact a mine field that imposes by far the greatest risk to the stability of your application.

    The WCF clients out of box scalabilty is zero and less. You never know when and what quota is blowing up next. If you want a scalable client you need to adopt every default quota for every possible binding.

    And who wants to do this for a client?

    Sure not me. All I want it to do is to communicate.

    But what are the benefits of client default quotas?

    The argument, that it helps preventing DOS attacks equals null here, because we are talking about a client, so a hacker controls all these parameters anyway. And a server cannot DOS attack a client, as clients can perfectly choose when and where to connect.

    So in summary:

    Client default quotas mean only great risk with no benefit. A client should offer quotas but not enforce them by default.



  2. Hi Tobias,

    The client quotas are mainly to enable clients and servers provided by different parties.  In REST and web applications it’s very common to write a client that hits a server who you have no idea who wrote the code for.  In intranet applications where the clients trust the server, we’ve never meant to discourage you from setting those quotas as high as you’d like.  We haven’t shipped the one click solution though that makes it easy to put your application in intranet mode.  That’s something we’re looking at for the future.

Skip to main content