Richard, Thank you - your comments have helped me find the solution. Slight hack in that I have to copy the service assembly to wherever the job assembly is located, but this allows the events to fire, and the AppDomain to be unloaded successfully. I've watched the memory of my service rise and fall again as the jobs run, whereas before it just kept rising constantly.
Cheers, Dino -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Dean Cleaver Sent: Friday, 14 September 2007 07:16 To: [email protected] Subject: Re: [ADVANCED-DOTNET] Correct handling of AppDomains Yes - I'm worried about not explicitly unloading the AppDomain. My concern with the AppDomain loading my service assembly is that they share 2 assemblies in common - 1 has the interfaces so will always be identical, but one other is just a support assembly that might change versions - ideally I'd like to avoid having to update the service, so I'll see if I can remove that second assembly. Also, the service is coded to find these other assemblies on demand by command line - the assemblies that it runs as jobs can be located anywhere, and won't have a copy of the service assembly in their folder - might have to explicitly load it from a path. Dino -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Richard Blewett Sent: Thursday, 13 September 2007 21:23 To: [email protected] Subject: Re: [ADVANCED-DOTNET] Correct handling of AppDomains It can be good practice to create a plugin manager for the jobs that you load into the separate AppDomain (it derives from MBRO) and then it loads the job locally in its AppDomain (removing the requirement that the jobs derive from MBRO). Your service knows about the plugin manager and communicates with the job via the manager. The manager acts as a site object to the job and mediates between you app and the job. So the job can register for events on the manager and the service tells the manager when these events should fire. However, I am confused about one thing. My assumption is that you load the job into a separate AppDomain so you can unload the job assembly when its finished (or maybe for extra isolation or both). If it is primarily about unloading the job assembly then thre is no issue with the service assembly being loaded into the job's appdomain. In these situations the primary issue you are trying to avoid is loading the plugin (job) into the default AppDomain which means you cannot completely unload it without terminating the process. Also AppDomains don't "go out of scope". You explicitly create them and unload them. When you unload one all the code executing in it gets terminated (the JIT Cache gets dumped, etc, etc). So is the issue simply that you are not explicitly unloading the AppDomain? Regards Richard Blewett - DevelopMentor > -----Original Message----- > From: Discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of Dean Cleaver > Sent: 12 September 2007 21:38 > To: [email protected] > Subject: [ADVANCED-DOTNET] Correct handling of AppDomains > > Hi, > > I'm writing an automation module that is designed to fire various jobs > (created as assemblies implementing a given interface). I'm using > AppDomains to create an instance of the job (via the interface so I > don't load the assemblies into my original AppDomain). > > The issue I have is that the jobs are asynchronous however I'm having a > hard time detecting when they're finished. If I try to add any events, > then the new AppDomain wants to load my service assembly. > > If the AppDomain goes out of scope, I presume the code in it will still > execute? And will it ever unload? I've searched the net for best > practises on AppDomains, but can find very little on this type of issue > - most is the basics of how to create one, perform an action and then > unload it. Some of my jobs are only a few seconds long, others several > hours, so I don't really want to run them synchronously. > > Cheers, > Dino > > =================================== > This list is hosted by DevelopMentor. http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
