如果是用IIS作host，下面的文章讲得很清楚：原文：http://www.ingorammer.com/RemotingFAQ/BINARYVERSIONMISMATCH.htmlDuring the lost month several people sent me questions regarding the following exception which only occurs when using the BinaryFormatter with an HTTPChannel when the server side object is hosted in IIS.An unhandled exception of type 'System.Runtime.Serialization. SerializationException' occurred in mscorlib.dllAdditional information: BinaryFormatter Version incompatibility. Expected Version 1.0. Received Version 1008738336.1684104552.I finally managed to reproduce the cause the leads to this exception - and suddenly, it became clear to me why I couldn't find it before.The reason for this is that the exception has absolutely nothing in common with a "version incompatibility". It is instead caused by to the fact that the client side binary formatter will always try to interpret the value that gets returned from the server as a binary encoded remoting message.So, guess what happens if the server outputs information like this:HTTP/1.1 500 Internal Server Error
Server: Microsoft-IIS/5.0
Date: Mon, 22 Apr 2002 21:25:44 GMT
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 3286<html>
<head>
<title>Configuration Error</title>
<style>
...
Well, in fact the client is trying to interpret this as a binary message. It will first check a header value (which should be "1.0" as indicated in the error message) to find the version number of the serializer used at the server side. Instead of receiving this number, the server will read the string "<htm..." and somehow translates this to "1008738336.1684104552". It them compares 1.0 to 1008738336.1684104552 and figures out that something must be wrong: it's a version mismatch ;-)
.......
Server: Microsoft-IIS/5.0
Date: Mon, 22 Apr 2002 21:25:44 GMT
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 3286<html>
<head>
<title>Configuration Error</title>
<style>
...
Well, in fact the client is trying to interpret this as a binary message. It will first check a header value (which should be "1.0" as indicated in the error message) to find the version number of the serializer used at the server side. Instead of receiving this number, the server will read the string "<htm..." and somehow translates this to "1008738336.1684104552". It them compares 1.0 to 1008738336.1684104552 and figures out that something must be wrong: it's a version mismatch ;-)
.......
In fact, I also have a little help for you to get to the "real" cause of this error message (in my case the message given from IIS has been "It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level".)I'd suggest to use Simon Fell's tcpTrace (from http://www.pocketsoap.com) to "intercept" the transferred data and look at the returned HTML code which will help you to figure out the root cause for this message. Let's say your server sits on port 80 of "localhost" and you want to check what really happens with it. In this case, start tcpTrace and set the following options: Listen on Port #: 81
Destination Server: localhost
Destination Port #: 80You will then have to reconfigure your client (using either a configuration file or in source code) to connect to the server via port 81 (instead of 80). This will now pass every byte that's transferred between your client and your server through tcpTrace and give you a chance to look at it.After starting your client and receiving the "Version mismatch"-exception, you can look at the tcpTrace's lower frame to see the real HTML message that has been returned by the server. In this message, the server will normally tell you what's wrong with it ;-)(Yes, I know it's alittle bit awkward, but it might be the only thing you can do to relieve some headaches.)Note: Please be aware that this technique only works with server-activated (a.k.a "Wellknown") objects. For client-activated object, the endpoint URL is generated by the server and will therefore always include the "real" port number.Note #2: Don't forget to reconfigure your client to use the original port after finding and fixing the problem!
In fact, I also have a little help for you to get to the "real" cause of this error message (in my case the message given from IIS has been "It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level".)I'd suggest to use Simon Fell's tcpTrace (from http://www.pocketsoap.com) to "intercept" the transferred data and look at the returned HTML code which will help you to figure out the root cause for this message. Let's say your server sits on port 80 of "localhost" and you want to check what really happens with it. In this case, start tcpTrace and set the following options: Listen on Port #: 81
Destination Server: localhost
Destination Port #: 80You will then have to reconfigure your client (using either a configuration file or in source code) to connect to the server via port 81 (instead of 80). This will now pass every byte that's transferred between your client and your server through tcpTrace and give you a chance to look at it.After starting your client and receiving the "Version mismatch"-exception, you can look at the tcpTrace's lower frame to see the real HTML message that has been returned by the server. In this message, the server will normally tell you what's wrong with it ;-)(Yes, I know it's alittle bit awkward, but it might be the only thing you can do to relieve some headaches.)Note: Please be aware that this technique only works with server-activated (a.k.a "Wellknown") objects. For client-activated object, the endpoint URL is generated by the server and will therefore always include the "real" port number.Note #2: Don't forget to reconfigure your client to use the original port after finding and fixing the problem!