BinaryFormatter Version incompatibility

Brian O posted on Tuesday, June 13, 2006

If posting here about CSLA 1.0 is not cool, please forward me to another forum.

OTW - can I get some help in how to debug a remoting call?

I have downloaded TCPTrace and tried to monitor this, but I think the path is too complicated. I have something like "server:port/directory/DataPortal.REM" and TCPTrace just allows me to enter server and port numbers.

The servers here have a core set of CSLA assemblies in the GAC along with Microsoft Enterprise Library stuff, and tons of verions of all of this with many versions of the "BusinessBase" assemblies in there. My code is working well without the remote invocation. The "DataPortal_Fetch" routine works well when all is local. I have checked the assembly version on the server to verify there is a match with my local compile.

TIA -Brian

brian.f.oneil@gmail.com

 

 

 

ajj3085 replied on Tuesday, June 13, 2006

Is the business assembly supposed to be loaded out of the GAC?  If it is, are you sure there isn't an older copy in the remoting web's bin directory?  It defaintly sounds like there's a version mismatch somewhere.

Brian O replied on Tuesday, June 13, 2006

Thanks for the speedy reply. I don't understand why it would matter what is in the Remoting Web's bin folder, since all applications look in the GAC first? OR am I wrong about this?

I am trying to match on the client-side with the highest version in the GAC of each assembly used by the remote server.

 

ajj3085 replied on Tuesday, June 13, 2006

Yes you are right, it should look in the GAC first... of course just to be safe, I'd double check the bin folder anyway.

However, I did see some articles that imply that Asp.Net will cache an assembly once its loaded.  So that may be a possiblity.

The second is that you may not have updated the web.config to tell Asp.Net to use the new version of the file.  I'd double check those. 

Let us know what you find.

Andy