I have a process, let’s call it Process A, that is hosting a simple WCF service exposed though a basic Http binding. If I spin up that process I can then access the service from another process, Process B, with no problems.
However, my required use case isn’t so simple. What I need to do is access the Service from a DLL that is hosting with Remoting. The Remoted DLL is spun up in a separate AppDomain by Process A and it is on the local machine.
When I call a method in the remoted DLL from Process A which in turn is supposed to call back to the WCF Service hosted in Process A the caller just hangs and after one minute I get a service timeout. The service code is never entered (a breakpoint that gets hit when calling it externally never is reached).
The fact that the Remoted DLL is able to create an instance of the client proxy class tells me (correct me if I’m wron here) that the configuration for the service is at least available in the Remoted client. It doesn’t complain about missing configuration info or throw an exception like it does in the external client if I remove the service reference.
So I guess my question is multi-part. First, can a Remoted DLL call a WCF service in the first place (i.e. is all of the requisite infrastructure available to the client)? If it can, what might I be missing? And how does one go about debugging something like this? Debugging remoting is painful when it’s a simple case – and this is not so simple.
One last thing – I can’t change the fact that I’m in a process that is remoting the DLL and that remoted DLL needs to consume the service. It’s a deeply entrenched part of the infrastructure of this app. I could, however, most the WCF service host to another process if it is of any use (and I might try that while waiting for any answers here).
In the end we removed Remoting copmpletely. It was a lot more work, but was the right thing to do.