Calling a .net 2.0 method from a .net 4.5 test causes a RemotingException

Question

In my solution I have a test project using .net 4.5 that calls methods on a class library project written in .net 2.0.

I have successfully called many methods (all functions), but one method (a Sub) is giving me a problem. It throws a RemotingException.

The method '...' was not found on the interface/type.

Intellisense works properly when I instantiate MyType in the test class. It's only when I try running the test that it throws the exception.

I have deleted the reference in my test project and readded it. I have added the reference as a "Solution" reference as well as a "Browse" reference.

Update 1

I switched my Sub to a Function and still received the RemotingException. The method I am calling in the .net 2.0 project is a new method that I added after I initially created the Test project and tests for all of the other methods.

Update 2

The class library is defined as such:

<ClassInterface(ClassInterfaceType.AutoDual)>
<Transaction(TransactionOption.Required)>
Public Class MyComponent
    Inherits ServicedComponent

And in the test, I am referencing the class like this:

<TestClass()>
Public Class MyTests

    Protected Property MyCom As MyComponent

    Public Sub New()
        MyCom = New MyComponent()
    End Sub

When I run my test, MyCom is created as this object instead of just an instance of MyComponent.

System.Runtime.Remoting.Proxies.__TransparentProxy

Answer 1

Ok, for anyone else that happens upon this issue, here is what I discovered.

In fact, rebooting wasn't the thing that solved my problem. It was that I had also re-registered my new dll in my locally running Component Services.

When you are testing a ServicedComponent and you create an instance of that ServicedComponent, it actually wraps a Remoting Proxy around the component that is currently running in COM+, and NOT the actual class that you're thinking you are debugging. Initially this wasn't an issue for me, but then I decided that I shouldn't be referencing my dll found in bin\debug directly from COM+, so I copied and moved it to another location. I did this because my build was hanging often when I would make changes to my ServicedComponent and rebuild my solution. Apparently when you build a ServicedComponent it attempts to put it into COM+ locally if there's not already a component of the same name already running there.

So by moving my dll and fixing my build hangup, I inadvertantly caused this issue. It's cool though because it led me to a much deeper understanding of how to test ServicedComponents.

I have since recreated my component in COM+ and am once again referencing the one in bin\debug. Which is nicely hanging when I build without shutting down the com application. It's a nice reminder letting me know that I'm actually testing against a real COM component in its own address space and not just an instance of my class that's in managed memory.

Cheers!