C# AppDomain and event handling question

[puffpio]

I have a program which creates new AppDomains and instantiates objects within those App Domains in order to safely execute stuff.

So lets call the initial App Domain #1, and the App Domain it creates #2.

I would like to set the event handler of the object inside of #2 to be a method that exists in #1

is this possible?

example code:

--------------

 

[imported_Dhaval00]

Two options:

1) Use Remoting (if using .NET 2.0)
2) Use WCF (if using .NET 3.5 - you can still use Remoting, but WCF makes more sense)

More or less, there is no way to directly raise events across appdomains (at least none that I know of).

 

[puffpio]

Basically I'm trying to fire an event when the object inside of the appdomain #2 is no longer active
then the appdomain #1 can shut down the appdomain #2

what I ended up doing was running a timer in the object in appdomain #2 to determine if it's no longer active..it then sets a boolean to indicate so
meanwhile, in appdomain #1, I poll the object inside #2 to see if that boolean is set..if it is, I shut down the appdomain #2

 

[hmandevteam]

Two options:
1) Use Remoting (if using .NET 2.0)
2) Use WCF (if using .NET 3.5 - you can still use Remoting, but WCF makes more sense)

i used this method http://hman.pastebin.com/2b7ng3Ss to raise event from plugin and it work fine if plugin generate event in first minutes, if plugin try to generate event after some stand by minutes, i obtain an exception:
Unhandled Exception: System.Runtime.Remoting.RemotingException: No receiver for uri

could you help me ?

 

[Oyster]

i used this method http://hman.pastebin.com/2b7ng3Ss to raise event from plugin and it work fine if plugin generate event in first minutes, if plugin try to generate event after some stand by minutes, i obtain an exception:
Unhandled Exception: System.Runtime.Remoting.RemotingException: No receiver for uri

could you help me ?

This is by design. When using Remoting, you can get burned if you do not know anything about LifetimeServices. Basically, when you obtain an instance from a Remoting server, you're on borrowed time - the client-side has five minutes (the default) to finish all the work using the proxy object.

If you idle for more than five minutes, the CLR will dispose the instance. This is obviously for memory management purposes. Since you haven't posted the details of your program, I'll go over a simplified scenario.

[Serializable]
class ServerAppDomain : MarshalByRefObject
{
    // Do work
}

class ClientAppDomain
{
    // Your Remoting proxy
    ServerAppDomain proxy = new ServerAppDomain;
}

In the above scenario, assume that the ClientAppDomain is where you request an instance of an object across contextual boundaries. The CLR will automatically serialize an instance of ServerAppDomain, import it into ClientAppDomain, and deserialize the instance of ServerAppDomain to make it usable. All this happens behind the scene - at the same time, the CLR knows that this is a Remoting object, so it allocates the default five-minute lifeline to the instance. If you do not utilize the proxy for five minutes, the Remoting object will be garbage collected.

So, when you try and invoke the a method using the "proxy" object in the ClientAppDomain, you'll get RemotingException. Which is counter-intuitive because your client still holds a reference to the server.

Long story short, this is a common possibility, wherein the client may be sitting idle for a long period of time. The way you can give your server an eternal life is by overriding the
InitializeLifetimeService() method in the ServerAppDomain and returning null. So doing the following should work:

[Serializable]
class ServerAppDomain : MarshalByRefObject
{
    /// <summary>
    /// Indicates to the Remoting environment that the lease 
    /// for the Remoting objects never expires.
    /// </summary>
    /// <returns>Null to indicate that the object stays alive forever.</returns>
    public override Object InitializeLifetimeService()
    {
        return null;
    }

    // Do work
}

Of course, I am assuming that the "lease expiration issue" is, in fact, the problem you're facing.