It looks like what you need is the plug-in architecture.
In this case, referencing of assembly is not an option. You can load an assembly during run-time using
System.Reflection or you can compile assembly out of source code and load it. Behind the scene, this second option is actually reduced to two steps: compilation and loading from a temporary file, but this can be hidden from you as an application developer. There is one more difficult option: emitting the assembly code during run-time using
System.Assembly.Emit.
The possible architectural solution are classified into two dramatically different classes: 1) if you need to load the plug-ins; 2) if you need to re-load them during run-time.
The second type of requirement makes programming way more difficult. However, this is quite doable.
The example of the second type if a kind of ".NET calculator" or a miniature "Visual Studio". If you want to enter some source code, compile it, process compilation errors, and, in case of success, load it and execute some loaded code,
you would need to unload loaded code every time you want to load the new one, otherwise you
would create a memory leak. The problem here is: there is
no a way to unload a loaded assembly! The solution is: load an assembly in a
separate Application Domain and unload the whole domain. Domain are very well isolated from each other, as well as different processes. In this way, you would have to work
throw the Application Domain boundaries, which is much more difficult. Essentially, the mechanism for passing data is IPC (Inter-Process Communication).
In my past solutions, I actually provided enough information and a good deal of advice. Please see:
Create WPF Application that uses Reloadable Plugins...[
^],
AppDomain refuses to load an assembly[
^],
code generating using CodeDom[
^],
Dynamically Load User Controls[
^],
how to Catch an unhandled exception thrown from a sub domain when calling a method by inkove(reflection)[
^].
Sorry, those posts are irregular, linked to each other; a log of information is repeated. Also, the very first inquirer asked overly tricky and vague question (probably did not really understand what he wanted), so I discussed overly difficult problems (out of fun, maybe) which should not concern you. The whole architecture should be simpler, the idea to compose a UI across Application Domain is wrong.
If you read them and still need an advice on your particular situation, please write a comment. Chances are, you will see a solution by yourself.
—SA
Submit an article or tip