none
Remoting error when COM+ client and COM+ component are both managed RRS feed

  • Question

  • I'm using (or rather attempting to use) a COM+ application (a ServicedComponent in .NET) to circumvent some permissions issues as I can run the COM+ app under a different identity.

    I've set up a project that uses regsvcs (x64 version) to install the COM+ app after a successful build. All of the COM+ requirements such as parameterless ctors and strong-naming have been adhered to. In my testing environment the COM+ app is on the same machine.

    I initially saw this error in my unit tests and thought it might be a bitness (x86 vs. x64) issue so I broke it out into an x64 test harness but the error remains the same which is:

    "This remoting proxy has no channel sink which means either the server has no registered server channels that are listening, or this application has no suitable client channel to talk to the server."

    Is it possible that when the COM+ client and COM+ component are both managed, the CLR tries to be clever and attempts to switch to using .NET remoting as a communication channel? If this is the case it's interesting as this page on MSDN specifically talks about Remoting being a "legacy technology that is retained for backward compatibility"

    What do I need to get around this issue? Is this something new brought on by some changes in .NET v4 as I have used this approach successfully in the past with no issues.

    Sample code:

    public class Foo: ServicedComponent
    {
        public Foo()
        {}
    
        public Foo Create(string p1, int p2)
        {
            // Do stuff
            return this;
        }
    
        public bool DoSomething(string p3)
        {
            // Do stuff here
            return true;
        }
    }
    
    public class FooUser
    {
        public FooUser()
        {
            Foo foo = new Foo().Create("One", 2);
            foo.DoSomething("Three"); // This line causes the error mentioned above
        }
    }

    I also tried to create an interface with the necessary methods and made the following modifications to my instantiating code based on some research:

    Type fooType = Type.GetTypeFromProgID("FooNamespace.Foo", "localhost");
    IFoo foo = (IFoo) Activator.CreateInstance(fooType);
    foo.Create("One", 2);
    foo.DoSomething("Three"); // Still the same error

    Sunt ludi et ioci dum aliquis oculo nocet.


    • Edited by noonand2 Friday, August 30, 2013 2:33 PM
    Friday, August 30, 2013 2:32 PM