Well, for one thing, it is not accompanied by the handy list of breaking changes to which we have become accustomed, so here is my own incomplete tally of the important things:

  • The change most likely to cause defects in existing code is in the way that behaviors are configured.  In earlier releases, one had a <behaviors> element, with one or more <behavior> elements therein.  Now, the <behaviors> element wraps a <serviceBehaviors> element and an <endpointBehaviors> element, which contain the individual <behavior> elements. 

<behaviors>

      <serviceBehaviors>

         <behavior name="MyServiceBehavior">

            <serviceDebug includeExceptionDetailInFaults="true"/>

         </behavior>

      </serviceBehaviors>

   <endpointBehaviors>

      <behavior name="MyEndpointBehavior">

         <clientCredentials>

               ...

            </clientCredentials>

      </behavior>

   </endpointBehaviors>

</behaviors>

 

  • The change most likely to delight is the addition of a way to specify base addresses for self-hosted services in configuration:

<service

   name="Microsoft.ServiceModel.Samples.CustomPeerResolverService">

   <host>

      <baseAddresses>

         <add baseAddress="net.tcp://localhost:8089/School/"/>

      </baseAddresses>

   </host>

   <endpoint

      address="PeerResolver"

      binding="netTcpBinding"

      contract="Microsoft.ServiceModel.Samples.IPeerResolver" />

</service>

 
  • The change most likely to cause surprise is having to explicitly enable metadata generation.  Just point your browser at the base address of your service, and you'll get instructions on how to do that.  I can see the wisdom of requiring the administrator to explicitly configure a service to expose metadata: it is part of making the Windows Communication Foundation secure by default.  However, history buffs will recall having to explicitly enable metadata generation in the October 2004 SDR version, but not having to do so from the April 2005 SDR version onwards ... and now finding themselves having to do it again. 
  • Program Manager Nicholas Allen has a five-part series of blog postings covering the changes to the channel layer.  Sam Gentile (who was kind enough to say nice things about my book) has a post that handily links to all five parts here: http://codebetter.com/blogs/sam.gentile/archive/2006/07/04/147092.aspx.  But allow me to summarize: building custom channels has gotten a little harder. 
  • Building an STS has changed somewhat, but when you have Gudge writing samples, why would you want to do that yourself? 
  • See the code snippet accompanying bullet #1 above to see how the returnUnknownFaultsAsExceptions behavior has morphed into includeExceptionDetailsInFaults. 
  • You will find that the exception messages have become postively sagacious.  They indicate, which surprising accuracy, the likely causes. 
  • The Peer Channel configuration language has been nicely enhanced so that now one configure Peer Channel applications for any scenario. 
  • The Service Trace Viewer now takes .svclog files rather than .e2e files as input, and the results are even more impressive than before. 
  • In cases where you might previously have wanted to put a KnownType attribute on a service contract, you would now put a ServiceKnownType attribute instead. 
  • [ServiceBehavior(Session=true)] is now [ServiceBehavior(SessionMode=SessionMode.Required)].