Of course we have to rebind our solutions, re-test and all, but hey, what don’t we do to get them internation characters delivered to our doorstep?

To understand the full conundrum let us back up a bit. Part of the receival of the documents is an enum with the name of the document type. Since we’re in Denmark and the web service is by another Danish company we do, of course, have some localised names with æ, ø and å in them — e.g. Lånebevilling. Now this is all great as long as we just remember to use utf-8 or iso-8859-1 as the charset type… or is it?

Using the DIME classes is fairly straightforward and not overly difficult so we were taken slightly aback when our web service client notified us that it had caught a Deserialization exception from the SOAP message — namely System.InvalidOperationException: ‘??’ is not a valid value for ResponseType.. With this extremely obvious error message I went spelunking in the badlands of the WSE1.0 implementation. After fruitless hours of looking through the disassembled code of the Microsoft.Web.Services.Dime namespace I sought help with the SOAP 3.0 toolkit and inserted a trace listener to see what actually went across the wire.

After about a days’ work pondering why it just didn’t work I came across an unsuspecting Encoding.ASCII.GetString call in the backlands of the Soap Deserializer. As the client very kindly tells me then å isn’t an ASCII character. Disappointed we were faced with two options: write our own DIME implementation or get our external partner to stop using locale specific characters. Neither a truly pleasing solution.

So to round all of this off then in this case the implementation doesn’t give a DIME about your country or its letters. Just keep to ASCII and everyone will be happy. Pity.