[.net] Plugin System - AppDomain only way to go?

Started by
7 comments, last by fenghus 19 years ago
I'm looking to create a plugin system for an application, and was wondering if creating new AppDomain instances for every plugin as they're loaded / unloaded is the only way to go. I don't want to load 100 plugins only to actually use 3 of them (aka Acrobat Reader effect) and I have to be able to dynamically unload them. Is AppDomain the only way to go? Or is there a different method I'm overlooking?
Advertisement
AppDomain is the only way to go. Your requirement of unloading every plugin demands it.
RegardsThomas TomiczekTHONA Consulting Ltd.(Microsoft MVP C#/.NET)
Hmmm... why are you worried about load? In .NET classes are only loaded when they are needed. Methods are only compiled when they're used.

Cheers
Well, IF he works on a server system that i s supposed to have a high uptime and load/unload plugins dynamicalle - you know, reading the documentation tells you that a class loaded once into an appdomain can not be unloaded.

So, if you have this requirement - which reading the OP will tell you he has, let me quote for you:

::and was wondering if creating new AppDomain instances for every plugin
::as they're loaded / unloaded is the only way to go.

See - he talks about load / unload.

Then separate AppDomains are simply the only way to go. The ONLY unit you can ever unload in a .NET application - besides the complete process - is the AppDomain.

This IS tricky at times (try opening a window in a separate AppDomain and have it behave like a dialog - not exactly trivial under all circumstances - but then, this is simply the only way.

But then, for this you need the requirement to be able to UNLOAD the plugins. Scrap this, and basically all complexities go overboard and you really are better on just loading the plugins into your main appdomain.
RegardsThomas TomiczekTHONA Consulting Ltd.(Microsoft MVP C#/.NET)
As he was comparing to Acrobat Reader I just wondered whether he was aware that his problem might be fictional. It's easy to make a plugin system that will only load components that are being used.

Of course only appdomains can be unloaded. I wondered if he realy needed that; if it is a real requirement...

Cheers
Of course, he could always just do a load on demand system.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

I'll post a follow-up so perhaps my intentions can be more clear.

I'm writing a plugin system for a C# IRC bot to allow custom / pluggable bots through a system of DLLs. You download the core bot, then fill up the DLLs directory with... "DiceRoller.dll" and "Trivia.dll" and "Google.dll". Each DLL will handle different commands (!roll, !answer and !google respectively).

So someone may load in the Trivia.dll on Saturday night, then once the trivia game is over, unload it to get back any system resources it used.

Am I on the right track with seperate AppDomains to do this?
As long as the app keeps on running: yes. However: communication between the appdomains is not trival compared to the 'ordinary' way of referencing dll's.

Cheers
Sounds like alot of work... how about just releasing the actual resources used by trivia.dll (string etc.) and keep the dll loaded... are you really that strapped for memory? Do some profiling to see if you can live with it... just my 0.5 krona.

This topic is closed to new replies.

Advertisement