2ne of the new items that were included in the .NET 3.5 framework is a built in way to add extensibility to your application using add-ins, also known as plug-in. Many of us have already added extensibility in our own application using interfaces. However this framework comes with a few built in features for addin lifetime management, security isolations etc.
If we want to add termination features to an addin we would need to load it to to different appdomain since we may want to unload it or reload it when any error happens. Also when the addin runs in a separate domain space it is less likely to corrupt any part of the application.
Please also note that when an addin is unloaded, the unloading causes the other assemblies to be unloaded as well on which the addin is dependent upon. This happens because the AppDomain is unloaded.
The new framework also supports discovery of addins within a folder. Also you can also search for a certain addin. According to the documentation each addin has its own folder and its own set of assemblies.
The security of the sandboxed addin can be created when we create the application domain for the addin to run on or we can even use the policy level security to control the addin behavior.
Versioning is provided via contract isolation, both the addin host and the addin itself can version independently of each other. A concept of adapter assembly is present for both the add in and the host so that the implementation can change independently.
Due to running the addin in different AppDomain boundary termination of the AppDomain automatically clears memory and all other resources. However if we needed to do this manually then we would have to find the application domain that hosts the assembly and unload it. The framework provides a nifty class to unload the addin and its AppDomain