Since we've spent some time talking about what doesn't work with serializers, let's look at some techniques for using an alternative serializer that I believe do work. At least, I don't know of a reason why these techniques don't work. You may find a reason why one of these doesn't work. If so, I'd be interested in knowing what goes wrong.

• Pass in your own instance of XmlObjectSerializer when working with messages. This is only an option when you're working directly with the messages rather than having the service turn messages into a strongly typed contract. Message operations take an overload so that you can provide the serializer. If you're using messages directly and you don't supply the serializer, then you get a custom instance of the data contract serializer.
• Substitute a sufficiently compatible serializer during the execution of a behavior. What went wrong with swapping the serializer out in a behavior last time was that other components may have already acted on parts of the service description by the time your behavior runs. Depending on the type of serializer swap you want to execute, this may not be an issue. For instance, if you want to replace the serializer with another that is the same type but has different settings, then it may be possible for you to replace the serializer without causing any visible side effects.
• Replace the serializer before attempting to start the service. Of course in the previous option, you always have to deal with the case where the serializer you want to use is not sufficiently compatible with the current serializer. In that case, the serializer can be replaced programmatically rather than through behaviors. Before the service starts, you can make whatever modifications you'd like to the service description and be certain that other code hasn't executed yet. Once you kick off the process of opening the service, then a chain reaction starts in which your potential options become increasingly constrained over time. The easiest way to avoid any problems is to not get into that game in the first place.

Next time: Security Failures as SYSTEM