Tricky Exception Message while Remoting...

Well, as you may know, I've recently taken a position at a new company. We are doing some really really cool stuff which, amongst other things, takes advantage of .NET Remoting, Service Oriented Architecture, MSMQ, Biztalk Server 2004 and Web Service Enhancements (WSE) 2.0 to name just a few. Well, fortunately we have some really brilliant developers who've helped me out quite a bit getting up to speed with what used to be a big weak spot of mine, Remoting.

So recently I was working on a few components and since they were pieces of our communications layer, they of course needed to be Remotable. If you aren't familiar with Remoting yet, you really owe it to yourself to learn it. I've avoided it for almost 3 years now and am quite embarassed that I did so. Ignoring the communications layer is something you don't want to do in any 'real' distributed environment. I'll be getting into the how's and why's shortly in some new articles I'm working on, but for the time being, trust me on this one. Anyway, I had gotten through about 60% of what I had to do and essentially I was using a reference to the .dll where I created my objects first to make sure they worked, then I removed the references to them, added a reference to their interfaces and remoted them. All was going well until I got to one of the SIMPLEST ones I had - it was simply a collection of Message Queue objects with some other custom information.

There was nothing fancy about this and everything else had been working. But each time I tried to create the object, I recieved a System.Runtime.Serialization.SerializationException with the following information:

 "An unhandled exception of Type 'System.Runtime.Serialization.SerializationException' occurred in mscorlib.dll. Additional Information: BinaryFormatter version incompatibility. Expected Version 1.0. Received Version 1008738336.1684104552'.

So I immediately took it at face value and figured I must have screwed something up in my .config file and specified the wrong Formatter Type. This didn't seem likely though because I didn't remember even writing any formatting information into the .config since well before this problem showed itself. Nonetheless I double checked my config settings and everything seemed correct. So I decided to check out google and came across this article from the Jedi Master himself. I had already read his book and didn't recall any mention of what this could be. After reading through the article I could safely conclude there was a problem here. Furthermore, I figured I'd stop wasting my time looking for problems related to the formatter - after all, he pretty much convinced me that the exception information was completely misleading. So, I decided to take his advice, use PocketSOAP and see what the server was returning. (This in and of itself is a bit of a daunting task at first, but I ASSURE YOU, it's well worth the effort because you'll learn a lot just walking through the excercise). Right there, clear as day was the source of my problem.... The assembly XXXXXXXXX wasn't found, and for good reason, the assembly name was XXXXXXXXXXXY. Even though I thought I carefully checked the spelling, the IDE doesn't typecheck your config entries so they are very prone to typos (which I make quite a few of). So I corrected the typo, tried again, and Boom, I'm off to the races. The reason I write this is mainly because this is one of those problems that can really give you some headaches. First off, you are probably going to try tracking down something that has NOTHING TO DO with the problem. So you may well change a few things (that work) all the while wasting valuable programming time. This is further reinforecement of the fact that if you don't know why you're changing something, you shouldn't change it. Furthermore, it reinforces the notion that you ought not to be using things that you don't understand and that taking time to really understand why things work the way they do will make your programming career a WHOLE lot better. And finally, although Ingo's article definitely tells you what the problem Isn't and how to find it, well, it puts the burden on you to figure out the rest.

If you've never read a tcpTrace then this might seem really too much to deal with. So to that end, I'll tell you that IF YOU'RE GETTING THIS ERROR

1) VERIFY THAT YOU'VE SPELLED EVERYTHING CORRECTLY

2) VERIFY THAT YOU'VE FULLY QUALIFIED YOUR NAMESPACES

3) MAKE SURE YOU AREN'T REFERENCING AN ASSEMBLY NAME WHEN YOU SHOULD BE REFERENCING AN OBJECT NAME, AND VICE VERSA

Ingo's article will give you everything you need to find this on your own and if you find that you just simply mispelled something or misreferenced it, I would still HIGHLY encourage you to walk through the process that he puts forth. After all, in this case it was easy to find the culprit but don't be lulled into thinking that this will always be the case - in all likelihood it won't. .NET Remoting isn't 'impossible' but it's also something that like threading, should be understood before you try to use it in production. There's a lot that can go wrong and tracking things down, particularly if you use the configuration files to set everything up (which trust me - is the only real way to do this), can be a good amount of work.

Finally, since Remoting is quickly becomming one of my new passions, I'd really like to hear your opinions/problems/likes/dislikes/troubespots etc - please write me at Bill AT KNOWDOTNET DOTCOM. I'd really like to hear from you. I'm going to do my best to discuss the pitfalls and roadblocks you may come across when learning Remoting so any and all feedback is greatly appreciated.