Actually it wasn’t that remote but it was to do with .NET Remoting. I wasn’t trying to do anything difficult yet getting a simple scenario to work resulted in a number of hours of tearing hair out. In a test application the remoting call would work fine but when I embedded the exact same code into the main application it would fail stating:
No connection could be made because the target machine actively refused it
You’d think this was some security issue but I tried everything I could think of (and a few more thanks to Google) and to no avail. In the end I ripped the solution apart – it turned out to be something wrong in the .suo file. Delete this file and I was good to go – ARGH!
The next issue I came up against was when I had changed a few things in the client application (the app that was going to call into the server application where the remote object had been instantiated). All of a sudden I was getting the following:
An existing connection was forcibly closed by the remote host
Now someone else has previously experienced this same issue and it turns out it might have something to do with the way that the VB team uses remoting to provide “single instance application” support in their application framework.
Building a simple send (ie client) and a simple receive (ie server) style application (which I had done earlier when trying to resolve the first issue) I tried enabling and disabling the “single instance application” feature on both sides. Turns out that it was only when I enabled this feature on the client application did I run into issues. This time I got the following exception information:
Authentication failure
Inner Exception: “Unable to read data from the transport connection: The connection was closed.”
I haven’t had a chance to work out exactly is conflicting between this feature and the ability to use tcpchannel remoting. Hopefully when I have time I’ll get to the bottom of it.