Re: Thank you and goodbye Mr Peter Morris

Unloading assemblies is not an issue for me. I load them when the app
starts, I create instances of classes within it as needed, when finished I
Dispose of those instances.

This is pretty much what I do, but that's because of the predictability of
my software and/or components that use plugins. It is enough for me to
close the application and copy or register the new plugin version and load
the application again. For websites, its even easier to just reset IIS.
For dev, resetting IIS is fine, for QA and production, this happens on a
schedule when everything is updated so resetting happens anyway.

I have only encountered one time the absolute need to load plugins into
AppDomains. The reason is because it was a custom service controller and if
a service went bonkers then the self-healing mechanism could kick in and
kill the appdomain without killing the other services that were loaded into
the host. The other reason is since the "servlets" would be deployed to any
number of hundreds of servers to data centers around the country to serve
the web application (an insurance application) we wanted the ability to
publish updates dynamically without interference: The old version would
continue to finish processing any existing requests and once the new servlet
was loaded into its appdomain, it would simultaneously take all new requests
and when the older version finished it would unload. In this respect we had
zero down time and were able to process hundreds of millions of transactions
daily. But for most uses that I've encountered, dynamic unloading of
assemblies has not been a concern but I'm also not targeting end users. My
tablature editor on the other hand, must support the feature.

There's a good book that discusses this in depth: "Customizing the .NET
Framework Common Language Runtime". Great book. "CLR via C#" 2nd Edition
also gives some good insight into ancillary concerns. Most of what you'll
find in the Customizing the .NET Framework CLR book is not easily
googleable; and what you do find via google is fragmented or not complete.


Thanks,
Shawn


.

Relevant Pages

  • ApplicationDomains
    ... Create new appdomain to "discover" all plugins and report them back ... Destroy discovery domain (To free assemblies/resources) ... I plan to use this in a service project, ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Cross domain performance
    ... I will assume there is no solution and I have to load the plugins in the ... main appdomain in order to perform at a respectable level. ... Calling in to these interfaces is what is slowing me down. ...
    (microsoft.public.dotnet.framework.performance)
  • Re: ApplicationDomains
    ... Basically, here's my plan: ... > 2) Create new appdomain to "discover" all plugins and report them back ... > 3) Destroy discovery domain (To free assemblies/resources) ...
    (microsoft.public.dotnet.languages.vb)
  • AppDomains and Remoting
    ... Make some nice plugins, and load those plugins into a ... , unload the Plugin AppDomain, and reload it, leaving ... and how would I load a form that is ... Like I said, maybe I'm barking up the wrong tree, or I'm ...
    (microsoft.public.dotnet.languages.vb)