Question

在我的解决方案中，我有一个使用.net 4.5的测试项目，它调用用.net 2.0编写的类库项目的方法。

我已经成功调用了很多方法（所有函数），但是一个方法（一个Sub）给了我一个问题。它抛出一个RemotingException。

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

当我在测试类中实例化MyType时，Intellisense正常工作。只有当我尝试运行测试时才会抛出异常。

我已删除测试项目中的引用并对其进行了重新读取。我已将引用添加为“解决方案”引用以及“浏览”引用。

更新1

我将Sub切换为Function并仍然收到RemotingException。我在.net 2.0项目中调用的方法是我在最初创建Test项目并测试所有其他方法后添加的新方法。

更新2

类库定义如下：

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

在测试中，我正在引用这样的类：

<TestClass()>
Public Class MyTests

    Protected Property MyCom As MyComponent

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

当我运行测试时，MyCom被创建为此对象，而不仅仅是MyComponent的实例。

System.Runtime.Remoting.Proxies.__TransparentProxy

Answer 1

好的，对于发生在这个问题上的其他人来说，这就是我发现的。

事实上，重启并不能解决我的问题。我在本地运行的组件服务中也重新注册了我的新dll。

当您测试ServicedComponent并创建该ServicedComponent的实例时，它实际上围绕当前在COM +中运行的组件包装了远程处理代理，而不是您认为正在调试的实际类。最初这对我来说不是问题，但后来我决定不应该直接从COM +引用我在bin \ debug中找到的dll，所以我将其复制并移动到另一个位置。我之所以这样做是因为当我对ServicedComponent进行更改并重建我的解决方案时，我的构建经常挂起。显然，当您构建ServicedComponent时，如果尚未在其中运行同名组件，则会尝试将其置于本地COM +中。

因此，通过移动我的DLL和修复我的构建挂断，我无意中导致了这个问题。这很酷，因为它让我对如何测试ServicedComponents有了更深入的了解。

我已经在COM +中重新创建了我的组件，并再次引用bin \ debug中的组件。当我在不关闭com应用程序的情况下构建时，这很好地挂起。这是一个很好的提醒，让我知道我实际上是在自己的地址空间中测试一个真正的COM组件，而不仅仅是我的类在托管内存中的实例。

干杯！

从.net 4.5测试中调用.net 2.0方法会导致RemotingException

1 个答案: