BizTalk Utilities CV ,   Jobs ,   Code library
 
Go to the front page to continue learning about XML or select below:

Contents

ReBlogger Contents

Previous posts in WSCF/WCF

 
 
Page 2324 of 18445

Orcas SP1 Beta Released

Blogger : BizTalk Blogs
All posts : All posts by BizTalk Blogs
Category : WSCF/WCF
Blogged date : 2008 May 13

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.

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.


Read comments or post a reply to : Orcas SP1 Beta Released
Page 2324 of 18445

Newest posts
 

    Email TopXML