Freigeben über

Orcas SP1 Beta Released

  • Artikel

Yesterday, a beta version of the first service pack for .Net Framework 3.5 was released including fixes and new features for WCF. The new features are primarily around serialization and tooling although there are enhancements scattered throughout many features.

All of the files are available for public download.

- Microsoft .NET Framework 3.5 Service Pack 1 Beta

[Microsoft .NET Framework 3.5 Service Pack 1 Beta Readme](https://download.microsoft.com/download/8/F/D/8FD2A9F0-C3D4-4B0A-80AF-88D738DCDDF4/dotNetReadMe.htm)

In addition to not being compatible with the previously released Silverlight SDK, there are two known issues for the beta.

HTTP POX is not composable with One-way

The OneWayBindingElement class is designed to create client-side channels that expect null messages as responses; otherwise, it fails with a ProtocolException error. Standard message encoders return messages that have a non-empty message body. However, in a POX/REST scenario, you may want to process messages based solely on the contents of HTTP headers (for example, 200 for success; otherwise, failure), rather than the message body. Because message encoders do not let you return null messages based on HTTP headers in these scenarios, it is not possible to use OneWay contracts on the client side.

To resolve this issue:

In the channel stack configuration, add a filter channel between OneWayBindingElement and HttpTransportBindingElement that checks the HTTP response status code. If the code indicates success, it returns null; otherwise, it returns the original response message. The final configuration appears as follows, with a custom binding element that filters the responses. CustomBinding binding = new CustomBinding( new OneWayBindingElement(), new MyMessageFilterByHttpHeaders(), new TextMessageEncodingBindingElement(), new HttpTransportBindingElement() ); binding.Elements.Find&ltMessageEncodingBindingElement>().MessageVersion = MessageVersion.None;

Windows XP issue when AllowNtlm is set to false

In WCF, if you specify the clientCredentialtype property as Windows and negotiate the client credentials, you can enable NTLM to be used as a negotiation package. The default behavior for WSHttpBinding and WS2007WttpBinding is to negotiate Windows client credentials. You can control this behavior in WCF by modifying the allowNtlm property. In the .config file, put the clientCredentials tag in an endpointBehavior tag. In the code, set a property on WindowsClientCredentials. There is a behavior change in SP1 that affects WCF running on all versions of Windows later than Windows XP. When allowNtlm is set to false, WCF in .NET Framework versions 3.0 and 3.5 would instruct spnego to use Kerberos as the negotiation package. The behavior change in SP1 excludes NTLM by passing additional information to the negotiation layer. This change enables additional sspi packages to be negotiated if they are available and supported by future versions of Windows. However, this functionality is not available in Windows XP, and users who set the AllowNtlm to false will experience problems.

To resolve this issue:

Set SecureConversation to false when you set AllowNtlm to false.

Comments