Loading and initializing modules at runtime

Aug 15, 2008 at 4:13 PM
I want the application to be capable of updating modules either via internet or by some sort of xcopy. What is the best way of loading a module for already running application and initializing it? This means also unloading some of the existing modules. Can the module perform some sort of TearDown when being unloaded in case the unload is supported of course?
Aug 19, 2008 at 1:56 AM
CompositeWPF cannot unload modules; this is not a limitation of the CompositeWPF - it is a .NET thing reference http://msdn.microsoft.com/en-us/library/ms173101(VS.80).aspx.   This isn't to suggest that it can't be done, reference GOOGLE search here, it will just require some work.

Aug 19, 2008 at 7:40 AM
Edited Aug 19, 2008 at 7:40 AM
Thanks for the response and links. I have experience working with application domains and loading/unloading assemblies. But I'm afraid this might be regarded as some fundamental part when speaking about modules within CompositeWPF block as rewiring module initialization seems more like a walkaround for limitations rather than feature implementation. Do you think "native" out-of-box multidomain support won't be sufficient for the products based on CompositeWPF?

With kind regards, Denis
http://dvuyka.spaces.live.com

Aug 19, 2008 at 12:34 PM
[Denis]  I have experience working with application domains and loading/unloading assemblies

Your the expert in this conversation then ;)  I've read up on them but in a world where user requirements/projects are constant (with tight suspenses) I've not been in a situation where we could consider them (we keep things simple and moving fast).   We find that Click-Once deployment meets our module deployment needs.

In light of your experience I'd be curious what the benefits would be?
Aug 19, 2008 at 2:03 PM
For simple example please imagine the IDE-based application where content, pads, ribbon items, etc are represented by different modules bringing logic besides UI injection. Some of the modules may also interoperate with web services, databases, etc. Assuming that modules in this case can be written by different teams you might want dynamic updates for some of them rather that closing the whole application to apply changes, or provide internet-based updates for the separate modules but not a click-once scenario for the overall application (very important feature in my opinion).
Speaking about single application domain like it is now we cannot unload any module without closing an aplication. Multiple application domains approach might provide possibilities for unloading modules (tear down procedure also appears here for correct removal of the module UI already injected into regions) and loading newer versions.
Level of CompositeWPF tuning in this case will make me require the full set sources rather than playing with virtual methods and modules enumerators, this is why I was speaking about possible needs of out-of-box support for that. I'm sure the "module unloading" questions will arise a lot of times as soon as more complex applications are being prototyped with CompositeWPF.
Aug 19, 2008 at 4:50 PM
Denis: I have experience working with application domains and loading/unloading assemblies

Bill: In light of your experience I'd be curious what the benefits would be?

If I might jump in to this conversation, I had a project quite a while ago where a desired use case was to allow updates to almost any part of the application without shutting the application down. This was in the context of a emergency dispatch center where they wanted pretty much zero downtime. Being able to really unload DLLs using UnloadLibrary was needed for this to work and we had to be careful that it was ok to do this before doing it. Yes it's not "safe" in the .net sense since there could potentially be objects using that code, but that's why we get paid the big bucks right?
Aug 19, 2008 at 5:30 PM
Edited Aug 19, 2008 at 5:30 PM
Yep, this is something I'm trying to explain. Very often it is quite critical for a scalable application not to be shut down while updating key components. If such support is not in the project plan for the nearest future we could at least collect the least minimum required for developers to replace the module loading behavior and easily enhance the existing model with unloading support.