I found the WCF version of the WSE3 compression filters on the Pablo Cribaro's blog where he published an updated WCF RC1 version.

This code was first released by Morty for WSE2. At that time we (Rodolfo Finochieti and I) make some improvements to that code, and later Rodolfo migrated this code to WSE3. Is very interesting how the community works....

The thing is the WCF version was having problems when used over a Named Pipes transport, so I decided to take some time and discovered some interesting behavior.

The problem occured in the ReadXml method of the CompressionMethod.cs class, and only fails when using TCP or NamedPipes, not on Http. So after doing some debugging I found that in the case of the Http transport, when the Xml Reader was reading an XmlNode with attributes it first reads the StartElement and after that an EndElement. This behavior changes when you are using Named Pipes and after reading the XmlNode that has some attributes, the reader skips the EndNode completely and positions itself on the nect XmlNode.

I first made a quick fix just by asking the XmlReader if the next node was an EndElement before trying to execute a ReadEndElement, but it seems too much as a hack so I tryied another approach.

In the attached file I publish an updated version of the compression library for WCF (for RC1) and modified the CompressionMethod.cs so it doesn't use attributes anymore, and in that way it works as expected regarding the transport being used.

If you ask me it looks like a bug on the XmlReader, because both messages was exactly the same (checked with trace) and this different behavior is totally unexpected.

I found other bug related to the use of Request/Reply channels with void contract methods. In that case a NULL message was sent back as response and therefore the code fails. On the CompressionInterceptor.cs class I have to check if the passed message was equal to null in the Compress and Decompress methods, and everything works as expected now.

Enjoy!

Andrés G Vettori
MCSE/MCSD/MCT
EDS Top Gun - .NET Capability Architect

Leader of the C# Community of the Microsoft Users Group Argentina

1 Comment

• cibrax said Friday, October 13, 2006 12:47:42 PM

  Hi Andres, I think the problem with the XmlReader can be solved if we use data contracts for the headers instead of manually reading and parsing the Xml. I did something like here, http://www.codeproject.com/winfx/WSI18N.asp I do not have enough time to test that change now, but I will try to do it next week. Thanks, Pablo.