Dynamically load types from add-in assemblies

Sep 29, 2008 at 10:41 AM
I have a main application that hosts the windows, comparable to Visual Studio (a simple empty environment, the add-ins decide how the environment is really implemented).

One of the methods I have developed is ShowDocumentWindow(string type). This method invokes a command in the environment that it should load the type (thus the window itself) and then show the document window in the environment.

However, I cannot load the assembly (or type) because the AddIn assemblies cannot be loaded on itself (probably because the AddInView assembly is not allowed to be in the add-in directory). How can I load and instantiate a type from an add-in based on the string representation of the type?

Thanks in advance!
Sep 30, 2008 at 10:45 AM
ok, this was kind of stupid. I used Assembly.Load. If you use Assembly.LoadFrom, it works perfectly!

If there is an easier way to load a type without known the assembly location, please let me know. Now, I have defined a method ShowDocumentWindow(string senderLocation, string type). The add-ins simply call this method using GetType().Assembly.Location.
Nov 3, 2008 at 1:50 PM
This doesn't solve my problem after all, because the add-in only knows the type of the add-in side and I now directly load it into the application domain of the host. If you have any ideas how to fix this, pleas let me know!
Nov 9, 2008 at 8:49 PM
Edited Nov 9, 2008 at 8:52 PM
Hi Tischnoetentoet

What exactly is your intention?
Do you want to load AddIns (by their name) on application start that were loaded when the apllication was last quit?
Do the AddIns show a surface in your application?
Is it Windows Forms or WPF?

orbit
Nov 12, 2008 at 1:57 PM
Our project consists of a host application that uses AvalonDock to make the UI very flexible. However, we want th real content to be located inside the add-ins. So, we want to load DocumentContent objects (UI elements defined in the add-ins) to be visible in the AvalonDock framework and also behaving as such.

We found a workaround by creating a DocumentContent container that can hold a UIElement control. Then, we pass the DocumentContent from the add-in to the host application. Then, the host application recognizes the call and creates an instance of the DocumentContent container. Next, it adds the UIElement which it gets from the add-in via the pipeline as a user control.

The DocumentContent placeholder simply invokes the Close event via the pipeline back to the original DocumentContent in the add-in (which is now being treated as a user control so it doesn't support the close event).

I hope you understand my problem (which isn't a problem anymore :)). This might be a useful post for other people because passing UI (especially customizable UI) via the pipeline is a nasty thing to implement (one you get the point, it's not that nasty anymore (but this is the case with the whole System.AddIn namespace)).

Thanks for your response! The application is WPF btw.