0

This one has had me stumped for a few hours now, and I have absolutely no ideas. I have the following remoting code:

private static IRolesAndResourcesManager InternalConnect(string host, string operatorName)
{
    string url = string.Format("tcp://{0}:{1}/IProxyFactory", host, ServicePort);
    object o = Activator.GetObject(typeof (IProxyFactory), url);
    IProxyFactory factory = (IProxyFactory) o;

    return factory.CreateRolesAndResourcesManager(operatorName);
}

When this is called from within our web site, it works fine. However, we also link to this same DLL from a WCF hosted service (basically, a console app). When I call the same method from within that process, I get an exception on the follow line:

return factory.CreateRolesAndResourcesManager(operatorName); // <-- Exception!

The exception is:

System.InvalidCastException: Return argument has an invalid type.\r\n at System.Runtime.Remoting.Proxies.RealProxy.ValidateReturnArg(Object arg, Type paramType)

Everything I've found so far says there's some sort of DLL mismatch; as if the WCF process was linked to an old version of the DLL. However, I've tried deleting every binary, cleaning, rebuilding. Heck, I've ever tried deleting the entire enlistment and checking out everything from Subversion again. I can also verify the CreateRolesAndResourcesManager method runs on the Remoting host side and returns valid data.

Is there anything else that can cause this sort of exception, besides a DLL mismatch? Is there any way to get more information on this error?

Update:

Definitely not a CLR version mismatch. All three processes (IIS Express, Remoting Host, WCF process) have the following Environment.Version:

{4.0.30319.18444}
    Build: 30319
    Major: 4
    MajorRevision: 0
    Minor: 0
    MinorRevision: 18444
    Revision: 18444

I've also ran Visual Studio as well as all processes as Admin to see if there's a security issue, but that doesn't fix the issue either.

Mike Christensen
  • 88,082
  • 50
  • 208
  • 326
  • 2
    Remoting is a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using WCF or ASP.NET Web API. See the note at the top of http://msdn.microsoft.com/en-us/library/vstudio/xws7132e.aspx for proof. – John Saunders May 27 '14 at 22:43
  • @JohnSaunders - Agreed. And every single answer on Remoting issues basically amounts to "Why are you still using Remoting?" Unfortunately, we don't have the bandwidth right now to update our entire code base. So, we'll be stuck with a hybrid of both for the time being. – Mike Christensen May 27 '14 at 22:57
  • "we don't have the bandwidth right now to update our entire code base." Was `bandwith` the word you intended to use? With things like BinaryFormatting and gzip compression I would be surprised if the bandwith difference was that large. – Scott Chamberlain May 27 '14 at 23:42
  • By *bandwidth* I meant the human development cost. It would take weeks or months to convert all our legacy services over, but we need this bug fixed for the next version. – Mike Christensen May 27 '14 at 23:52
  • Does CreateRolesAndResourcesManager actually return a IRolesAndResourcesManager? The error suggests the service is trying to return an object that does not implement IRolesAndResourcesManager. – Erik Funkenbusch May 28 '14 at 00:52
  • @ErikFunkenbusch - It does. I've also compared all the assembly info and it matches. And I did a file compare on the DLL the website links to and the DLL the WCF service links to, and they're identical. I'm completely stumped. – Mike Christensen May 28 '14 at 01:13

1 Answers1

1

This question and answer:

System.InvalidCastException when creating a client activated object using an older version of an interface defined in a strong named assembly

Suggests that if the version of the .NET CLR used in the server and client are different, this error can occur, and that with .NET Remoting they both have to be the same version of the CLR. I'm not certain if that is the case, but you might want to check....

Community
  • 1
  • 1
Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291
  • Ooh I'll check that tomorrow when I get back into the office! Good hypothesis! – Mike Christensen May 28 '14 at 01:25
  • @MikeChristensen - I've also seen mention that this can occur when the DLL that contains the assembly can't be located correctly. Apparently, this can be somewhat tricky on occasion. You have to have the same assembly on both sides of the connection, I gather. – Erik Funkenbusch May 28 '14 at 01:27
  • As in the exact same assembly on disk? Meaning, I can't "Copy Local"? Or, just byte-for-byte the same assembly? I've ran a file comparison tool on both assemblies and there's zero differences between them. Plus, it works when I call it from the website and that's loading from the IIS bin directory. – Mike Christensen May 28 '14 at 01:30
  • @MikeChristensen - No, not the exact same assembly.. I meant two copies. In general, this error seems to mean the assembly can't be loaded for some reason, either because of strong naming, conflicting CLR versions, multiple assemblies with the same definition, can't find the assembly, etc... It could also be CAS related as well... – Erik Funkenbusch May 28 '14 at 01:32
  • The assembly can definitely be loaded, since I'm using all sorts of types from it. If I do a `typeof(IRolesAndResourcesManager ).Assembly()` under the debugger, all the versions and GUIDs match up on both sides. The CLR version is a possibility. I was also gonna run the WCF service as an admin to see if there's any security issues involved, though I'd expect to see a different exception if that were the case. – Mike Christensen May 28 '14 at 01:39
  • No go on the version thing; all components target .NET 4.5 and use the same runtime. I've also tried running as admin. I do appreciate the advice though! – Mike Christensen May 28 '14 at 15:40
  • 1
    @MikeChristensen - You could try enabling assembly binding logging and looking for errors. http://msdn.microsoft.com/en-us/library/e74a18c4%28v=vs.71%29.aspx Be warned, I once forgot to turn this off and a few months later found my machine to be crawling... and found gigabytes of log files that took forever to delete... – Erik Funkenbusch May 28 '14 at 15:44
  • Sounds like it's worth a shot. My other option was to install a packet sniffer and look at the network traffic.. – Mike Christensen May 28 '14 at 15:47
  • Fixed it! The binding logs *really* helped out here and pinpointed the exact error. Basically, the WCF service didn't have a reference to the assembly that held the return type of the Remoting service (though it did have a reference to the interface said return type implements, which is why Visual Studio could highlight it). As for why `typeof(IRolesAndResourcesManager)` resolves under the VS debugger, I guess because VS can see types loaded into any process it's attached to. Very confusing! – Mike Christensen May 28 '14 at 16:11