Preventing Unexpected Application Failures from Partially Trusted Add-Ins
If your application loads partially trusted add-ins, you might need to take steps to prevent add-ins from causing the host application to stop responding or close unexpectedly. Failures can occur if an add-in throws an unhandled exception or enters an infinite loop when your application calls the add-in (for example, the application invokes a delegate or executes a macro).
Preventing the Host Application from Closing Unexpectedly
If an add-in causes the host application to close unexpectedly, the most likely cause is an unhandled exception in the add-in. In the .NET Framework 2.0 and later, unhandled exceptions from any thread will cause the process to exit. This means that a partially trusted add-in can end the host application's process if the add-in is called on an application thread that is not wrapped in a try/catch block—for example, a call from a timer event.
To help prevent unhandled exceptions from causing the host application to close unexpectedly, you can load partially trusted add-ins into an external process. This provides the highest level of protection for your application, although it might affect the performance of calls between the application and the add-ins. For more information about loading add-ins into an external process, see Discovering and Loading Add-Ins.
If you do not want to load add-ins into an external process, you can consider the following options:
If the host application is managed, wrap all calls to add-ins in try/catch blocks. Unmanaged applications that use COM interop to communicate with add-ins typically do not have to wrap calls to add-ins in try/catch blocks, because the COM interop layer automatically catches all managed exceptions and converts them to HRESULT values.
Enable the unhandled exception policy of the .NET Framework version 1.0 and 1.1 for your application. New managed threads are then automatically wrapped in try/catch blocks, which helps to prevent unhandled exceptions. For more information about enabling the unhandled exception policy, see Exceptions in Managed Threads.
If the host application is unmanaged, you can use the host interfaces for the .NET Framework 2.0 and later to start the common language runtime with the unhandled exception behavior of the .NET Framework version 1.0 and 1.1 enabled. For more information, see Hosting Interfaces for the .NET Framework 2.0 and Later.
Note
Do not grant ControlThread permission to partially trusted add-ins. Add-ins that have ControlThread permission can create a new thread that is not wrapped in a try/catch block, even if you enable the unhandled exception policy of the .NET Framework version 1.0 and 1.1. If add-ins for your application must be able to create threads, you can provide a method in your proxy assembly that creates threads that are wrapped in try/catch blocks.
Preventing Add-ins from Causing the Host Application to Stop Responding
If an add-in enters an infinite loop, the host application might stop responding if it is waiting for a call to return. To protect the host application from this situation, you can load partially trusted add-ins into an external process. This might be the only way to prevent some issues that can cause host applications to stop responding. For example, an add-in might be able to create an infinite loop in a finally block, because the common language runtime will not interrupt a thread while it is executing a finally block. For more information about loading add-ins into an external process, see Discovering and Loading Add-Ins.
If you do not want to load add-ins into an external process, consider making all calls to the add-in on a new thread.
See Also
Concepts
Discovering and Loading Add-Ins