[WCF]WCF New Changes From Feb CTP to Beta2-优快云博客

本文档描述了WCF FebCTP版本到Vista Beta2版本之间的重大变化，包括ASP.NET集成模式的更名、WSDL导入元素的类型更改、HTTP映射模式的标准化等。此外还涉及安全性改进、队列消息属性的封装以及一些公共对象模型（COM）可用性的提升。

申请博客已经这么长时间了,一直忙于项目,今天抽出时间,发表第一篇日志.
这篇日志来自于微软的官方网站,因为微软已经把WFX整合进Framework,改名
为Framework 3.0. 所以,前一阶段的Feb CTP必然会有改动,具体大家可以参考
下面,有问题,可以一起讨论.

http://wcf.netfx3.com/content/BreakingChangesbetweenFebCTPandVistaBeta2.aspx

This document describes the breaking changes between the WCF Feb CTP and Vista Beta2. C# code examples are provided in some sections. There are only a few changes between these releases because the Vista Beta2 release was locked down shortly after the Feb CTP. 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. They will also show up as removed from their old namespace and added to their new namespace in the detailed api change reports.

Link this URI for details:

http://wcf.netfx3.com/content/DetailChangeReportFebCTPtoVistaBeta2.aspx

ServiceModel

Change	Rename ASP.NET Integration Mode to ASP.NET Compaitibility Mode
Type of Origin	System.ServiceModel.AspNetIntegrationRequirementAttribute
This change effects	OM;Config
Before	AspNetIntegrationRequirementsAttribute AspNetIntegrationRequirementsMode enumeration
After	AspNetCompatibilityRequirementsAttribute AspNetCompatibilityRequirementsMode enumeration
Code Before [AspNetIntegrationRequirements( RequirementsMode = AspNetIntegrationRequirementsMode.Allowed )] <system.serviceModel> <serviceHostingEnvironment aspNetIntegrationEnabled="true" /> </system.serviceModel>
Code After [AspNetCompatibilityRequirements( RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed )] <system.serviceModel> <serviceHostingEnvironment aspNetCompatibilityEnabled="true" /> </system.serviceModel>

Change	WsdlImporterElement and PolicyImporterElement return an object of type string instead of "Type"
This change effects	OM
Before	WsdlImporterElment.Type PolicyImporterElement.Type return an object of type Type
After	WsdlImporterElment.Type PolicyImporterElement.Type return strings

Change	Fixed capitalization of HttpMappingMode.SoapWithWSAddressing
Description	The enum member SoapWithWsAddressing was renamed to SoapWithWSAddressing to match the platform standard for capitalizing short acronyms.
Type of Origin	System.ServiceModel.Channels.HttpMappingMode
This change effects	OM

Security

Change	INTEROP: Align SecurityAlgoritmSuite with WS-SecurityPolicy
Description	Aligned System.ServiceModel.Security.SecurityAlgorithmSuite with WS-SecurityPolicy terminology. The values of the algorithmSuite attribute in the configuration are changed in the same way as the members of SecurityAlgorithmSuite class.
Type of Origin	System.ServiceModel.Security.SecurityAlgorithmSuite
This change effects	OM;Config
Before public abstract class SecurityAlgorithmSuite { static public SecurityAlgorithmSuite Default static public SecurityAlgorithmSuite Aes256 static public SecurityAlgorithmSuite Aes192 static public SecurityAlgorithmSuite Aes128 static public SecurityAlgorithmSuite Rsa15Aes128 static public SecurityAlgorithmSuite Rsa15Aes256 static public SecurityAlgorithmSuite TripleDes static public SecurityAlgorithmSuite TripleDes128 static public SecurityAlgorithmSuite TripleDes192 static public SecurityAlgorithmSuite Rsa15TripleDes192 ... }
After public abstract class SecurityAlgorithmSuite { static public SecurityAlgorithmSuite Default static public SecurityAlgorithmSuite Basic256 static public SecurityAlgorithmSuite Basic192 static public SecurityAlgorithmSuite Basic128 static public SecurityAlgorithmSuite TripleDes static public SecurityAlgorithmSuite Basic256Rsa15 static public SecurityAlgorithmSuite Basic192Rsa15 static public SecurityAlgorithmSuite Basic128Rsa15 static public SecurityAlgorithmSuite TripleDesRsa15 static public SecurityAlgorithmSuite Basic256Sha256 static public SecurityAlgorithmSuite Basic192Sha256 static public SecurityAlgorithmSuite Basic128Sha256 static public SecurityAlgorithmSuite TripleDesSha256 static public SecurityAlgorithmSuite Basic256Sha256Rsa15 static public SecurityAlgorithmSuite Basic192Sha256Rsa15 static public SecurityAlgorithmSuite Basic128Sha256Rsa15 static public SecurityAlgorithmSuite TripleDesSha256Rsa15 ... } public static class SecurityAlgorithms { ... public const string RsaSha256Signature = "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"; public const string HmacSha256Signature = "http http://www.w3.org/2001/04/xmldsig-more#hmac-sha256"; }

Change	Remove CredMan support from security code
Description	Originally, client credentials provider used information from Windows CredMan when username/password or client certificate credentials were not specified in the proxy behavior. After this change, we no longer look into CredMan when credentials are not specified. Users are advised to use InfoCards credentials provider instead to get equivalent functionality.
This change effects	public behavior change

Change	Change Spnego, Tlsnego to not use composite duplex
Description	If Spnego/Tlsnego was configured over CompositeDuplex, it used the CompositeDuplex factory below it. This meant that the reply-to header of the RST message could not be secured in the case of SPNego, Tlsnego. It was possible for an attacker to cause the server to send the RSTR to a different address by tampering with the reply-to of the RST. This constituted a DOS threat. Bindings using composite duplex are targets of DOS attacks since the server initiates a connection to the reply-to in the message. The mitigation for this has been for the binding to be configured with security authentication. However, certain bootstrap security protocols like Spnego, Tlsnego establish the client authentication - during these protocols the client's identity is not yet established. A server can be DOS'd if these protocols operate over a composite duplex binding.
This change effects	Wire
Before	Spnego/Tlsnego used the CompositeDuplex factory below it.
After	SPnego / Tlsnego now use the underlying transport connection directly even if the app binding has composite duplex layered over the transport.

Queues

Change	Encapsulation of all Msmq message properties in a single class
Type of Origin	System.ServiceModel.MsmqIntegration.MsmqIntegrationMessageProperty
This change effects	OM
Before	MSMQ message properties mapped directly to the Indigo message properties. On the channel level, Indigo message properties collection contained directly MSMQ message properties. The reference types stored as is and value types are boxed and made Nullable<>. There’s a helper class which encapsulates all property names as strings. If MSMQ property not set, the Indigo property is absent. If (indigoMessage.Properties.HasKey[MsmqPropertyNames.Priority]) { Console. WriteLine((indigoMessage.Properties[MsmqPropertyNames.Priority] as MessageProperty?).Value); } On the SFx level, MsmqMessage<T> implements [MessageContract]. For each msmq property it has a strongly-typed public getter (and setter if applicable) which wraps a private field declared as [MessageProperty].
After	There’s a single Indigo property which encapsulates all MSMQ message properties. The latter are accessible through public getters and setters (if applicable). If the MSMQ property is not set, the corresponding getter gives null. All value types are represented in the form of Nullable<>. It is an error to send a message using integration channel without this property. MsmqIntegrationMessageProperty property = MsmqIntegrationMessageProperty.Get(indigoMessage); Invariant.Assert(null != property); If (property.MessagePriority.HasValue) { Console.WriteLine(property.Value); } On the ServiceModel level, MsmqMessage<T> contains an instance of MsmqIntegrationMessageProperty and trivialy delegates all getters and setters to it. MsmqIntegrationMessageProperty is marked as [MessageProperty] so it can be stick to the indigo properties collection by the serializer.
Code Before if (indigoMessage.Properties.HasKey[MsmqPropertyNames.Priority]) { Console. WriteLine( (indigoMessage.Properties[MsmqPropertyNames.Priority] as MessageProperty?).Value); }
Code After MsmqIntegrationMessageProperty property = MsmqIntegrationMessageProperty.Get(indigoMessage); Invariant.Assert(null != property); if (property.MessagePriority.HasValue) { Console.WriteLine(property.Value); }