This document describes the breaking changes between the June CTP release and RC1. C# code examples are provided in some sections. There are only a few changes between these releases. The changes in this list are primarily motivated by improving OM usability. Some changes have been made to facilitate industry interop. And some have been made for security reasons.
Not all types involved in a change are mentioned here. Types will not show up in this report that have just been moved to a different namespace. If you have Visual Studio, searching for moved types in the object browser is an easy way to find their new namespace.
We hope you will find it useful in moving your existing WCF code to the Jun CTP.
Change
Default Value of MaxConcurrentCalls now 16
Description
The MaxConcurrentCalls throttle controls the number of threads that we can have active in a single service at any given time. In the past our default was 64, which biased toward throughput on many-cpu'd (16 cpu+) machines, but can lead to very high memory usage on smaller (1-4 cpu) machines running several services.Our new default (16) is tuned for performance and memory usage on 1-4 cpu machines, for both small and large numbers of services.
Type of Origin
System.ServiceModel.ServiceThrottlingBehavior
This change effects
OM;#Config
Don't accept "TooLarge" values for time spans when configuring channels
The maximum size of a TimeSpan for several configuration settings has been restricted to 2^32 milliseconds (approximately 49 days). This affects the following settings:AcknowledgementIntervalChannelInitializationTimeoutIdleTimeoutInactivityTimeoutIssuedCookieLifetimeLeaseTimeoutMaxClockSkewMaxCookieCachingTime MaxOutputDelayNegotiationTimeoutReplayWindowRetryCycleDelaySessionKeyRenewalIntervalSessionKeyRolloverIntervalTimestampValidityDurationTimeToLive
System.ServiceModel.Channels
Config
Name change: EnableFlowControl to FlowControlEnabled in ReliableSessionBindingElement
System.ServiceModel.Channels.ReliableSessionBindingElement
Before
namespace System.ServiceModel.Channels{ public class ReliableSessionBindingElement { public bool EnableFlowControl { … } }}
After
namespace System.ServiceModel.Channels{ public class ReliableSessionBindingElement { public bool FlowControlEnabled { … } }}
Code Before
<reliableSession enableFlowControl="true"/>
Code After
<reliableSession flowControlEnabled="true"/>
Change in default values of MaxPendingChannels and MaxTransferWindowSize properties in ReliableSessionBindingElement
The previous defaults were too high. (1) MaxPendingChannels is the maximum number of channels we create on the receiver and in the pending state waiting to get accepted. The channel is created upon receiving a Create Sequence Request and a response to it is sent. The channel is then enqueued in the input channel queue. This property is to indicate the maximum number of channels that can be enqueued in the in the input channel queue. When the quota is reached, we refuse to accept any more channels. Channels will also get taken out of the pending state if inactivity timeout kicks in and the sequence is faulted. Too high a value -we impact throughput and we found we were using up a lot of memory. Too low a value on the other hand would mean we are not servicing to capacity. Applying tradeoff we arrived at 4.(2) The transfer window size indicates how many messages to hold on the receive and send side. On the send side it is an indication as to how many unacknowledged messages can be held in the window and on the receive as to how many messages can be held for dispatch. Too large a transfer window size, we again impact memory use impacting performance. On stress runs with the old default of 32 and with message size of 64K we found 2MB of reserved space of long living objects --spinning up a bunch of threads that blocks on GC.We traded off the transfer window size to 8.With both these values -we now have as listener backlog reserved space of 2MB (4*8*64K) instead of 16 MB previously. We expect this would cover 80% of scenarios where RM would be used.
Change in default value of reliable session binding element properties.
Change in defautl values only. (MaxPendingChannels was 8 and MaxTransferWindowSize was 32)
Change in default values only. (MaxPendingChannels is now 4 and MaxTransferWindowSize is now 8)
No change
MetadataExchangeClient how uses an XmlDictionaryReader with the default quotas
The MetadataExchangeClient now uses enforces the default XmlDictionaryReaderQuotas.
System.ServiceModel.Description.MetadataExchangeClient
OM
A SOAP WSDL binding is no longer exported when EnvelopeVersion.None is specified
A SOAP WSDL binding is no longer exported when EnvelopeVersion.None is specified in the endpoint binding
System.ServiceModel.Description.WsdlExporter
Fixing X505CertificateValidationMode.ChainTrust on Vista
behavior
X509CertificateValidationMode.ChainTrust and X509CertificateValidationMode.PeerOrChainTrust were identical when running on Vista. This was because the chain building and validation semantics changed on Vista platform.
X509CertificateValidationMode.ChainTrust accepts only certificates that successfully chain up to one of the trusted roots and it does not take into account certificates stored in the TrustedPeople store.
Fixing FIPS compliance checking on Vista
Behavior
WCF didn't detect FIPS compliance setting on Vista because the registry key location changed from downlevel platforms.
WCF correctly detects FIPS compliance setting on Vista platform.
Fixing digest algorithms enforcement
Digest algorithm specified at the algorithm suite wasn't enforced on structures that use digests in the received messages.
Digest algorithm specified at the algorithm suite is being correcly enforced for received messages.
RequireClientEntropy and RequireClientEntropy assertions are no longer exposed in WSDL
WSDL format change
The sp:Trust10 assertion wasn't emitted in the WSDL unless the authentication mode required WS-Trust protocol to be used to SCT negotiation. In case of STS, the sp:Trust10 assertion needs to be emitted even if the STS authentication mode does not require WS-Trust protocol, because it is used to indicate for example the supported entropy mode.
sp:Trust10 assertion is always emitted to the WSDL with the exception of BasicHttpBinding.
Add New Exception type for AccessDenied semantics
A new exception type was added to signal authorization failures.
System.ServiceModel.Security.SecurityAccessDeniedException
CardSpace Namespace Changes
OM;#Config;#Wire
Namespaces that were once based off:"http://schemas.microsoft.com/ws/2005/05/identity"
"http://schemas.xmlsoap.org/ws/2005/05/identity"
CardSpace CRD file format change
<IssuerName> is removed from the CRD file format
OM;#Wire
[Serializable] now added to collection and IXmlSerializable types
When we generated code before with ImportOptions.GenerateSerializable=true (svcutil.exe /serializable switch), we used to not generate [Serializable] attributes on collection types and IXmlSerializable types. We will now generate [Serializable] on these types.
Generated proxy code
Svcutil now supports multiple IMetadataExchange endpoint configurations
Svcutil.exe will now use the IMetadataExchange endpoint configuration that has the same name as the URI scheme of the specified metadata endpoint address. If no endpoint configuration is found, svcutil.exe will try to use one of the MetadataExchangeBindings.
Svcutil tool behavior
Default generated client constructors use new wildcard behavior when loading endpoint configurations
The generated default client constructor passes the wildcard character '*' to its underlying ChannelFactory<T>. The wildcard character specifies that if there is only one endpoint configuration for the given contract it should be loaded, otherwise an exception is thrown.
Copyright © 2006 Microsoft Corporation. All Rights Reserved. | Terms of Use | Privacy Statement | Contact Us