Be very careful when you decide to start updating your code to .NET 2.0. One thing I found out (the hard way!) is that there is apparently some .NET code loaded into the inetinfo.exe process, which causes inetinfo.exe to load version 2.0 of the framework.

This was a problem because we also had some SMTP sink, implemented in .NET 1.1 that we wanted to load. Now, it actually works OK - .NET 1.1 assemblies can generally work with version 2.0 of the framework... except when you want to serialize thing with the binary serializer – you won’t be able to deserialize them with a .NET 1.1-only binary.

The problem for us was that we had some transport sinks install in the SMTP server, where we serialized incoming messages, put them on an MSMQ queue, and then tried to read them off the queue in a .NET 1.1 service. It gave us the very informative error message when it tried to deserialize:

Isn’t it completely obvious what the problem is there? I didn’t think so either. Note also that I haven’t actually compiled anything with .NET 2.0, I’m just running my transport sinks on a machine which has .NET 2.0 installed.

Now, apparently you can get a fix from Microsoft (instructions here) but in order to get the patch, you need to contact PSS and open a support ticket! Why don’t they release the patch to the public?

Luckily for us, our infrastructure has a version-independent serialization mechanism that isn’t tied to the .NET framework version. So I have to modify all our MSMQ-related code to use that instead of the binary serializer.