.NET：使用 AppDomains 引发和处理事件时出现问题

Question

这是我的问题的基本要点：

1. 我的主 Window 类实例化 A 类。A
2. 类在辅助 AppDomain 中实例化 B 类。
3. B 类引发事件，A 类成功处理该事件。
4. A 类引发了自己的事件。

问题：在步骤 4 中，当 A 类从捕获 B 类事件的事件处理方法中引发其自己的事件时，该事件就会引发； 但是， Window 类中的订阅处理程序永远不会被调用。

没有抛出任何异常。 如果我删除辅助 AppDomain，则该事件的处理不会出现问题。

有谁知道为什么这不起作用？ 有没有另一种方法可以在不使用回调的情况下完成这项工作？

我认为，如果有的话，问题将出现在步骤 3 而不是步骤 4。

这是一个真实的代码示例来说明该问题：

Class Window1

    Private WithEvents _prog As DangerousProgram    

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles Button1.Click    
        _prog = New DangerousProgram()
        _prog.Name = "Bad Program"  
    End Sub

    Private Sub MyEventHandler(ByVal sender As Object, ByVal e As NameChangedEventArgs) Handles _prog.NameChanged
        TextBox1.Text = "Program's name is now: " & e.Name
    End Sub

End Class


<Serializable()> _    
Public Class DangerousProgram

    Private _appDomain As AppDomain
    Private WithEvents _dangerousProgram As Program
    Public Event NameChanged(ByVal sender As Object, ByVal e As NameChangedEventArgs)


    Public Sub New()

        // DangerousPrograms are created inside their own AppDomain for security.

        _appDomain = AppDomain.CreateDomain("AppDomain")    
        Dim assembly As String = System.Reflection.Assembly.GetEntryAssembly().FullName 
        _dangerousProgram = CType( _   
                    _appDomain.CreateInstanceAndUnwrap(assembly, _    
                        GetType(Program).FullName), Program)

    End Sub


    Public Property Name() As String
        Get
            Return _dangerousProgram.Name
        End Get
        Set(ByVal value As String)
            _dangerousProgram.Name = value
        End Set
    End Property


    Public Sub NameChangedHandler(ByVal sender As Object, ByVal e As NameChangedEventArgs) Handles _dangerousProgram.NameChanged    
        Debug.WriteLine(String.Format("Caught event in DangerousProgram. Program name is {0}.", e.Name))
        Debug.WriteLine("Re-raising event...")

        RaiseEvent NameChanged(Me, New NameChangedEventArgs(e.Name))   
    End Sub

End Class


<Serializable()> _    
Public Class Program
    Inherits MarshalByRefObject

    Private _name As String
    Public Event NameChanged(ByVal sender As Object, ByVal e As NameChangedEventArgs)

    Public Property Name() As String
        Get
            Return _name
        End Get
        Set(ByVal value As String)
            _name = value
            RaiseEvent NameChanged(Me, New NameChangedEventArgs(_name))
        End Set
    End Property   

End Class


<Serializable()> _   
Public Class NameChangedEventArgs
    Inherits EventArgs

    Public Name As String

    Public Sub New(ByVal newName As String)
        Name = newName
    End Sub

End Class

Answer 1

.NET 事件的魔力隐藏了这样一个事实：当您通过 A 的实例订阅 B 的实例中的事件时，A 会被发送到 B 的应用程序域中。 如果 A 不是 MarshalByRef，则发送 A 的值副本。 现在您已经有了 A 的两个独立实例，这就是您遇到意外行为的原因。

如果有人很难理解这是如何发生的，我建议使用以下解决方法，它可以清楚地说明为什么事件会发生这种情况。

为了在 B（在 appdomain 2 内）中引发“事件”并在 A（在 appdomain 1 内）中处理它们而不使用真实事件，我们需要创建第二个对象来转换方法调用（无需太多麻烦就可以跨越边界）事件（其行为与您预期的不同）。 这个类（我们称之为 X）将在 appdomain 1 中实例化，其代理将被发送到 appdomain 2 中。代码如下：

public class X : MarshalByRefObject
{
  public event EventHandler MyEvent;
  public void FireEvent(){ MyEvent(this, EventArgs.Empty); }
}

伪代码将类似于：

1. A，位于 AD1 中，创建一个新的应用程序域。 称之为AD2。
2. A 在AD2 上调用CreateInstanceAndUnwrap。 B 现在存在于 AD2 中，B_（代理） 存在于 AD1 中。
3. A 创建X 的实例。
4. A 将 X 交给 B_（代理）
5. 在 AD2 中，B 现在有一个 X_(proxy) 实例（X 是 MBRO)
6. 在 AD1 中，A 向 < strong>X.MyEvent
7. 在AD2中，B调用X_(proxy).FireEvent()
8. 在AD1中，FireEvent在X上执行，这会触发MyEvent
9. A的事件处理程序FireEvent 执行。

为了让 B 在 AD1 中触发事件，它不仅必须具有该方法，而且还必须具有触发该方法的实例。 这就是为什么我们必须将 X 代理发送到 AD2 中。 这也是为什么跨域事件需要跨域边界编组事件处理程序的原因！事件只是方法执行的一个奇特的包装器。 为此，您不仅需要方法，还需要执行该方法的实例。

经验法则必须是，如果您希望跨应用程序域边界处理事件，则两种类型（公开事件的类型和处理事件的类型）都必须扩展 MarshalByRefObject。

Answer 2

在我第一次尝试解决此问题时，我删除了 B 类 对 MarshalByRefObject 的继承，并将其标记为可序列化。 结果是对象按值封送，我刚刚获得了在主机 AppDomain 中执行的 C 类 的副本。 这不是我想要的。

我发现，真正的解决方案是 B 类（示例中的 DangerousProgram）也应该继承自 MarshalByRefObject，以便 调用back 还使用代理将线程转换回默认的 AppDomain。

顺便说一句，这是一篇很棒的文章，我发现埃里克·利珀特（Eric Lippert）以非常聪明的方式解释了裁判元帅与价值元帅。