I think I might know what this problem is. I tried remoting to our webserver once and had an error because the remote objects were coming back with the wrong IP address attached - its a multi-IP server. I would have thought that remoting was smart enough to return the right one, but something was going wrong. So I had to alter the server config file to always return the server hostname rather than an IP, forcing the clients to resolve it. It fixed the problem though... I used the machineName attribute for my http channel and set useIpAddress to false. Maybe thats the cause of your problems? Hope it helps. Andy
----- Original Message ----- On the off chance that it's something silly before we go too much farther down the debugging road...did you actually remember to call RemotingConfiguration.Configure in both the client & server? If you forgot to do that, you could end up with the error message you're getting. > Firstly I changed the config files on the client and server > so that they > are both using tcp/binary. That wouldn't have changed anything wr2 your problem, that was more of an aside by me wondering why you were using such an odd channel/formatter configuration. > I also tried the Assembley Binding Log Viewer but it didn't > display any > messages on either the client or server machines after I ran the > applications with the viewer running in the background. Ok - that would indicate you're not suffering an assembly resolution failure on either side. > When you > said 'enable logging of errors' did you just mean to select the 'Log > Failures' check box Yes. > The assembly deployment matches your description. A stand in-class is > deployed in the same folder as the client application on > machine X and the > actual implementation of the assembly is placed in the same > directory as > the server application on machine Y. Can you elaborate on "stand in class"? Is this an assembly produced by soapsuds? Or one your wrote yourself? I think at this point it would be more efficient if you posted a small test case reproducing your client/server assembly layout that we could look at. > Looking back over the error I think this is something to do > with how the > server application or machine is configured.It appears that > the client is > marshalling the event sink and attempting to forward it to > the server but > the server is rejecting it for whatever reason (maybe a > security setting, > but wouldn't that raise a security exception?). > You never answered the question about hosting (or I've missed it somewhere in this thread). What is the nature of your "server application". Is it IIS/ASP.NET hosting your server code, which is in a library assembly? Or an NT service? Or a Windows Forms application? Etc... -Mike DevelopMentor http://staff.develop.com/woodring
