Breaking Changes between Vista Beta2 and June CTP

Before

<configuration>
  <appSettings>
    <add key="baseAddress"
         value="http://localhost:8000/ServiceModelSamples/service" />
  </appSettings>
  <system.serviceModel>
    <services>
      <service
          name="Microsoft.ServiceModel.Samples.CalculatorService">
        <endpoint address=""
             binding="wsHttpBinding"
             contract="Microsoft.ServiceModel.Samples.ICalculator" />
       </service>
    </services>
  </system.serviceModel>

</configuration>

//Code to create ServiceHost
Uri uri = new Uri(ConfigurationManager.AppSettings["baseAddress"]);
ServiceHost serviceHost =
    new ServiceHost(typeof(CalculatorService), uri);

After

<configuration>
  <system.serviceModel>
    <services>
      <service
          name="Microsoft.ServiceModel.Samples.CalculatorService">
        <host>
          <baseAddresses>
            <add
    baseAddress="http://localhost:8000/ServiceModelSamples/service"/>
          </baseAddresses>
        </host>
        <endpoint address=""
             binding="wsHttpBinding"
             contract="Microsoft.ServiceModel.Samples.ICalculator" />
       </service>
    </services>
  </system.serviceModel>
</configuration>

//Code to create ServiceHost
ServiceHost serviceHost = new ServiceHost(typeof(CalculatorService));

Before

<behaviors>
  <behavior name="MyServiceAndEndpointBehavior"
            returnUnknownExceptionsAsFaults="false">
     <!-- behavior elements can implement IServiceBehavior or IEndpointBehavior-->
  </behavior>
</behaviors>

After

<behaviors>
    <serviceBehaviors>
        <behavior name="MyServiceBehavior">
            <serviceDebug includeExceptionDetailInFaults="false" />
  <!-- all behavior elements implement IServiceBehavior -->
        </behavior>
    </serviceBehaviors>
    <endpointBehaviors>
        <behavior name="MyEndpointBehavior">
  <!-- all behavior elements implement IEndpointBehavior -->
        </behavior>
    </endpointBehaviors>
  </behaviors>

Change

Misc Cleanups to ServiceModel Runtime OM

Description

This change was a collection of small cleanups to runtime object model.  The cleanups included:

 o The SynchronousReceiveBehavior was moved from the System.ServiceModel to the System.ServiceModel.Description namespace.

 o TransferMode was moved from the System.ServiceModel.Description to the System.ServiceModel namespace.

 o IContextChannel is now IExtensible

 o IDispatchFormatter and IClientFormatter were renamed to IDispatchMessageFormatter and IClientMessageFormatter

 o Renamed a few types from "Proxy" to "Client"

 o Moved ConcurrencyMode and InstanceContextMode from ChannelDispatcher to DispatchRuntime

 o Added a ChannelFactory<T>  (Binding, string) overload ctor

 o Added a DuplexChannelFactory constructor overload that takes in the callback type o Removed ChannelFactory<T>.CreateChannel<U>

 o Added ChannelFactory.CreateChannel() static method

 o Remove ChannelFactory.CreateEndpointAddress

 o Add DispatchRuntime.ValidateMustUnderstand

This change effects

OM

Change

Behavior Configuration Cleanup: Move Behaviors Off <behavior> Element

Description

In this release we've done quite a bit of work to make behavior configuration less error prone.   The first change is to move behaviors and settings that had been attributes on the <behavior> element to their own elements.  The two elements created are <serviceTimeouts> and <serviceDebug>, which you can see used in the "after" code snippet.  Two settings, "openTimeout" and "closeTimeout", are properties of the ServiceHost itself, so we've moved those to the <host> element.  Note that the "instanceContextIdleTimeout" property was cut with the removal of Shareable instances.

For more information on helpPage configuration, see the entry in this list regarding Metadata Configuration.

This change effects

OM;#Config

Before

    <behaviors>
      <behavior name="MyBehavior"
                returnUnknownExceptionsAsFaults="false"
                closeTimeout="00:01:00"
                openTimeout="00:01:00"
                instanceContextIdleTimeout="00:01:00"
                transactionTimeout="00:00:00">

  <!-- other behavior elements -->

      </behavior>
    </behaviors>

After

    <service>
      <host>
        <timeouts closeTimeout="00:01:00"
                  openTimeout="00:01:00" />
      </host>
    </service>
    <behaviors>
      <behavior name="MyBehavior">
        <serviceTimeouts transactionTimeout="00:00:00" />
        <serviceDebug httpHelpPageEnabled="True" helpPageUrl="" includeExceptionDetailInFaults="false" />
  <!-- other behavior elements -->
      </behavior>
    </behaviors>

Change

Behavior Configuration Cleanup: Clarify Behavior Scope

Description

In previous releases of WCF, configuration files allowed users to have mixed collections of behaviors, including both IServiceBehaviors and IEndpointBehaviors.  This ambiguity led to quite a bit of confusion, so we've introduced strongly-typed behavior container elements, <serviceBehaviors> and <endpointBehaviors>

This change effects

OM;#Config

Before

// [app|web].config before the changes:
<behaviors>
  <behavior name="MyServiceAndEndpointBehavior">
     <!-- behavior elements can implement IServiceBehavior or IEndpointBehavior-->
  </behavior>
</behaviors>

// machine.config after the changes:
<commonBehaviors>
  <!-- behavior elements can implement IServiceBehavior or IEndpointBehavior-->
</commonBehaviors>

After

// [app|web].config after the changes:
  <behaviors>
    <serviceBehaviors>
        <behavior name="MyServiceBehavior">
  <!-- all behavior elements implement IServiceBehavior -->
        </behavior>
    </serviceBehaviors>
    <endpointBehaviors>
        <behavior name="MyEndpointBehavior">
  <!-- all behavior elements implement IEndpointBehavior -->
        </behavior>
    </endpointBehaviors>
  </behaviors>

// machine.config after the changes:
  <commonBehaviors>
    <serviceBehaviors>
  <!-- all behavior elements implement IServiceBehavior -->
    </serviceBehaviors>
    <endpointBehaviors>
  <!-- all behavior elements implement IEndpointBehavior -->
    </endpointBehaviors>
  </commonBehaviors>

Change

Behavior Configuration Cleanup: Clarify Behavior Element Names

This change effects

OM;#Config

Before

    <!—the following configuration elements support IServiceBehavior -->
  <metadataPublishing />
  <throttling />
  <xmlFormatter />
  <serviceCredentials />
  <serviceAuthorization />
  <serviceSecurityAudit />

    <!—the following configuration elements support IEndpointBehavior and apply to Client-only -->
  <clientCredentials />
  <channelViaUri />

    <!—the following configuration elements support IEndpointBehavior and apply to Service-only -->
  <matchAllEndpoints />

    <!—the following configuration elements support IEndpointBehavior and apply to Both -->
  <synchronousReceive />
  <transactedBatching />

After

    <!—the following configuration elements support IServiceBehavior -->
  <serviceDebug />  NEW 
  <seviceTimeouts />  NEW 
  <metadataPublishing />  RENAME  <serviceMetadata />
  <throttling />  RENAME  <serviceThrottling /> 
  <xmlFormatter />  RENAME  <dataContractSerializer /> 
  <serviceCredentials />
  <serviceAuthorization />
  <serviceSecurityAudit />

    <!—the following configuration elements support IEndpointBehavior and apply to Client-only -->
  <clientCredentials />
  <channelViaUri />  RENAME  <ClientVia viaUri="" /> 

    <!—the following configuration elements support IEndpointBehavior and apply to Both -->
  <synchronousReceive />
  <transactedBatching />
  <dataContractSerializer />  SUPPORT AT BOTH ENDPOINT SCOPES  

Change

Changes to fault behavior

Description

When an unexpected exception took place when processing a request in RC0, the service would typically not send back any reply.  In order to get a reply, you would turn on "ReturnUnknownExceptionsAsFaults", which would send back a fault with minimal error information.

In RC1 we're changing the behavior to always send back a fault when the service hits an unknown exception.  To see more detail about the unknown exception, you can set the new knob "IncludeExceptionDetailInFaults".  This sends back a serialized form of the unknown exception that got in the way of your service processing.  This change affects both services and clients configured to process callbacks.

The exception information sent when IncludeExceptionDetailInFaults is turned on conforms to the following DataContract:

    [DataContract]
    public class ExceptionDetail
    {
        public ExceptionDetail(Exception exception)
        public override string ToString();
        // get-only properties:
        [DataMember]
        public string HelpLink
        [DataMember]
        public ExceptionDetail InnerException
        [DataMember]
        public string Message
        [DataMember]
        public string StackTrace
        [DataMember]
        public string Type
    }

As part of this change we also renamed <clientDebug> and <clientTimeouts> to <callbackDebug> and <callbackTimeouts>, both in config and OM, since these refer to the callback of a duplex client.

This change effects

OM;#Config;#Wire

Before

<serviceDebug returnUnknownExceptionsAsFaults="true />

<clientDebug returnUnknownExceptionsAsFaults="true />

<clientTimeouts ...>

After

<serviceDebug includeExceptionDetailInFaults="true />

<callbackDebug includeExceptionDetailInFaults="true />

<callbackTimeouts>

Change

Remove InvalidCardinalityAddressingException and Add MessageHeaderException

Description

o Removed the unused exception type, InvalidCardinalityAddressingException

o Added the new exception type, MessageHeaderException, for use when we run into problems calling Message.Headers.Find (and the typed properties)

This change effects

OM

Change

MessageContract changes

Description

1) Message contracts are now wrapped by default, not bare. To get pre-RC1 behavior back, set IsWrapped=false.
2) (not really a breaking change) Guidance around MessageContract has changed. It is now acceptable to have more than one body member (in wrapped mode) instead of using a wrapping data contract
3) MessageBodyAttribute renamed to MessageBodyMemberAttribute

This change effects

OM;#Wire

Code Before

//Change #1 (must change)
[MessageContract] public class SomeMessage
{ [MessageBody] public string someField; }

//Change #2 (guidance)
[MessageContract] public class SomeMessage
{ [MessageBody] public SomeDC contents; }
[DataContract] public class SomeDC {
[DataMember] public string contents1;
[DataMember] public string contents2; }

Code After

//Change #1 (must change)
[MessageContract(IsWrapped=false)] public class SomeMessage
{ [MessageBodyMember] public string someField; }

//Change #2 (guidance)
[MessageContract(WrapperName="contents")] public class SomeMessage {
[MessageBodyMember] public string contents1;
[MessageBodyMember] public string contents2; }

Change

Close throws CommunicationObjectFaultedException when the object is faulted

Description

A race condition existed between calling Close on a CommunicationObject and observing the Faulted event on that object.  This race could cause Close to appear to terminate successfully when in fact it has downgraded to Abort and performed a dirty shutdown.

We have fixed this by changing the behavior of Close to always throw an exception when called on a faulted object.  It was previously possible for an exception to occur here although it was rarely seen.  Code that called Close to clean up a faulted object should instead call Abort directly.

Type of Origin

System.ServiceModel.ICommunicationObject

This change effects

behavior

Change

System.ServiceModel.Identity: The name is too generic given the namespace

Type of Origin

System.ServiceModel.Identity and descendants

This change effects

OM

Before

System.ServiceModel.Identity
System.ServiceModel.DnsIdentity
System.ServiceModel.RsaIdentity
System.ServiceModel.SpnIdentity
System.ServiceModel.UpnIdentity
System.ServiceModel.X509CertificateIdentity

After

System.ServiceModel.EndpointIdentity
System.ServiceModel.DnsEndpointIdentity
System.ServiceModel.RsaEndpointIdentity
System.ServiceModel.SpnEndpointIdentity
System.ServiceModel.UpnEndpointIdentity
System.ServiceModel.X509CertificateEndpointIdentity

Change

Cut InstanceContextMode.Shareable

Description

As part of cutting the Shareable instance context mode, the following OM changes were made:

//Cut from IClientChannel:
  EndpointAddress ResolveInstance();
  IAsyncResult BeginResolveInstance(AsyncCallback callback, object state);
  EndpointAddress EndResolveInstance(IAsyncResult result);

// Cut from ChannelDispatcher:
  public InstanceContextMode InstanceContextMode;

// Cut from InstanceContext:
  public SynchronizedCollection<AddressHeader> Headers

// Cut from InstanceContextMode:
Shareable,

//Changed from IShareableInstanceContextLifetime
public interface IInstanceContextLifetime

//Cut from BehaviorElement
  public TimeSpan InstanceContextIdleTimeout

Type of Origin

System.ServiceModel.InstanceContextMode

This change effects

OM;#Behavior

Before

System.ServiceModel.InstanceContextMode.Shareable

Code Before

// Users specify Shareable in the ServiceBehaviorAttribute
[ServiceBehavior( InstanceContextMode=InstanceContextMode.Shareable )]

Code After

// Users who wish to have Shareable instances will have to use the extensibility interfaces to implement this themselves.
// A sample implementation will be included in the SDK

Change

Generalize InstanceContext extensibility interfaces

Description

This change provides a mechanism to look up an existing InstanceContext, complimenting the existing InstanceContextInitializer interface for dealing with new InstanceContexts.  Further, this change adds a property for setting the InstanceContextProvider on System.ServiceModel.Dispatcher.ChannelDispatcher.

Together, these pieces of OM allow users to implement their own InstanceContext modes.  A sample will ship with the SDK that demonstrates this.

Type of Origin

System.ServiceModel.InstanceContextProvider

This change effects

OM

After

public interface IInstanceContextProvider :
{
//This will throw if the user returns a newly created InstanceContext as we cannot apply instance throttling on user created InstanceContexts.
InstanceContext GetExistingInstanceContext(Message message);
}

//Add a new field for InstanceContextProvider on DispatchRuntime
public IInstanceContextProvider InstanceContextProvider
{
get{}
set{}//Can throw ArgumentNullException
}

Change

Removed extra constructor for OperationContext

Type of Origin

System.ServiceModel.OperationContext

This change effects

OM

Before

Public OperationContext(ServiceHostBase host);

Code Before

// Pass a ServiceHostBase to the OperationContext constructor
OperationContext o = new OperationContext(aServiceHostBaset);

Code After

// Use the other OperationContext constructor, passing an IConstactChannel
OperationContext o = new OperationContext(anIContextChannel);

Change

Poison message properties change in NetMsmqBinding and MsmqIntegrationBinding

Description

There are 3 change