I love writing extensible applications, so I was very interested in attending this PDC session. The obvious approach to writing managed add-ins is to simply load any assemblies that are registered as add-ins, use reflection to look for specially-marked types in each assembly, create instances of those types, and communicate with those instances. This session talked about potential problems with that approach and discussed solutions.

One problem is that old add-ins won’t work with new versions of the application (and vice-versa) because of strong naming. This problem is solved by using non-versioned, stable interfaces for any communication between the application and the add-in.

If the add-in assembly is loaded directly, the assembly can’t be unloaded if the add-in is unloaded. This can be solved by loading the assembly into its own app domain, or even in its own process. Also, the add-in must run under the same security as the application unless it is loaded into its own app domain or process. Another potential problem is that the add-in must use the same version of the CLR and the .NET Framework, but the only way around that is to load the add-in into a separate process.

Of course, loading an add-in into its own app domain has its own problems. Objects that are passed between the application and the add-in must be serializable or marshal-by-ref, which can be more work, and decreases performance. Loading an add-in into its own process provides even worse performance, and communication between the two becomes even more difficult.

The speakers thus recommended loading add-in assemblies into their own app domains, and spent the rest of the session explaining the add-in model used by the new System.AddIn namespace. Unfortunately, I was pretty lost for most of the presentation; it can’t be as complicated as it seemed…

In any case, I’ll still consider the direct approach for loading add-ins if I ever need them for a desktop application. Leaving an add-in assembly loaded even after the add-in is unloaded is not a significant problem for short-lived client apps. Giving add-ins full trust seems a bit dangerous, but if you trust an add-in developer enough to run their installer, it’s not a stretch that you need to trust their add-in as well.