This week I had a hard day to track down a remoting issue we had with our product. We have a application service running (Windows Service or Console Window for tests) under CLR 1.1 and a ASP.NET 2.0 application want to call the service. After figuring out an issue with a third party software component I got another exception: "Serialization Error: Unknown member TextInfo". I'm talking about remoting serialization of function parameters and return values, not using/calling any formatter like SOAP. Diving into the problem analysis I found our software never uses such a member and so I examined a involved CLR class that member is part of using reflector: the CaseInsensitiveHashCodeProvider class used indirectly by an own collection inherited from NameObjectCollectionBase. I know MS worked hard to get the old style collections compatible to the new implementations using Generics and new approaches and so it is with that base collection. It is mentioned at the .NET 2.0 obsolete type/member list the collection is using a new preferred constructor with the IEqualityComparer parameter and they wrap up the old style HashCodeProvider and Comparer with a internal class named CompatibleComparer.
Knowing all that now I had to find a way to get around the serialization exception. It happens the moment the CLR 1.1 running at the app service try to deserialize the CLR 2.0 serialized collection. I started to create some experimental own HashCodeProvider classes and one that worked recently had the original (don't change the semantic!) CaseInsensitiveHashCodeProvider hold as a non-serialized member and just serialized the CultureInfo.Name to be able to re-create it on creation/deserialization implementing ISerializable and IDeserializationCallback to set the private members ("_hashProvider" and "_comparer" using reflection - they can only be set via the costructor!) of NameObjectCollectionBase. We had to replace the Comparer also, because after it serialized/deserialized our migratable HashCodeProvider successfully we got another wired exception we had to workaround by a homebrewed Comparer class implemented similar to our HashCodeProvider class.
Now it works fine. What we learned? Also MS don't keep in mind to consider also internal classes to provide backward compatible serialization formats. They used only the code attribute "Serializable" and don't implement ISerializable to explicitly get compatible serialization. I expect to get more issues like this... :-(
Update: It looks like the new cool feature named VTS (version tolerant serialization) will not work for Net.Remoting, isn't it?