0

I'm working on updates to a deployed client server app that uses .net remoting over a tcp channel with the binary formatter. As the clients are geographically distributed, I need to make updates server-side only where possible. The system uses .net 3.5, and the client and server have a shared dll which contains a well-known implementation class. This dll does not have a strong name.

The problem I have is that when I update the server and try to deploy the modified version, clients fail, logging an error message as follows:

    Cannot load type '(service class name), (assembly name), Version =1.0.0.0, Culture = neutral, Public Key Token = null'

The details specified in the error match the details of an assembly deployed in the same directory as the client.exe file, so I don't really understand why the client doesn't load it. Yes, the client has a different version to the server, but the version numbers are the same, so it should work, shouldn't it?

Jules
  • 14,841
  • 9
  • 83
  • 130
  • It may or may not be relevant that the updates add a new external dependency to the server's copy of the implementation assembly. – Jules Dec 11 '12 at 01:05

1 Answers1

0

Turns out thatt this is the hazard of trusting your client's previous contractor... I had simply assumed that the source they provided corresponded to the deployed system, but it seems as though they gave me an out of date version. The particular problem causing this error is that between the version they gave me source for and the deployed version they changed the name of the namespace that contains the well known service object, thus the error that it couldn't be found in the assembly as deployed.

Jules
  • 14,841
  • 9
  • 83
  • 130