WPF: Architecture for hosting third party. NET Plug-ins

Last November, Bloomberg L.P. Launched the application portal, an application platform that independent Third-party software developers can use to sell to more than 300,000 users of Bloomberg professional services based on Microsoft. NET Framewor K Windows Presentation Foundation (WPF) application.

In this article, we'll introduce a common architecture for hosting third party "untrusted". NET applications, similar to the architecture used by the Bloomberg application portal. The accompanying source code (archive.msdn.microsoft. Com/mag201308plugins) contains a reference implementation of the. NET plug-in host and the demo plug-in, which uses the Bloomberg API to draw a historical pricing information chart for a given security.

Plug-in host architecture

Figure The architecture shown in 1 contains both the main application process and the plug-in hosting process.

Figure 1 architecture to host the. NET plug-in

Developers implementing the plug-in hosting infrastructure should carefully consider the advantages and disadvantages of implementing the plug-in host as a stand-alone process. As far as the application portal is concerned, we firmly believe that the benefits of this approach outweigh the disadvantages, but we will list the most important factors you need to be aware of.

The benefits of implementing the plug-in host as a stand-alone process include:

It separates the main application process from the plug-in, which reduces the likelihood that plug-ins will have any negative impact on the performance or availability of the application. It reduces the risk of plug-ins blocking the UI thread of the main application. In addition, it is unlikely to cause memory or any other critical resource leaks in the main process. This approach also reduces the likelihood that a poorly written plug-in could cause a "managed" or "unmanaged" unhandled exception to slow down the main application process.

It is possible to improve the security of the entire solution by applying sandbox technology similar to the sandbox technology used by the Chromium Projects (see Bit.ly/k4v3wq for more information).

It leaves more virtual memory space for the main application process (this is more important for 32-bit processes, which are limited by the 2GB free virtual memory space of the process user-mode code).

It allows you to use the. NET plug-in to extend the functionality of non. NET applications.

The disadvantages are mainly related to the increased complexity of the overall implementation:

You need to implement a separate interprocess communication (IPC) mechanism (especially when the main application process and plug-in host have different versions or deployment loops, pay special attention to version control of the IPC interface).

You must administer the lifetime of the plug-in hosting process.

Implementing user security is one of the major issues to consider when designing a hosting process for untrusted Third-party plug-ins. The topic of defining the appropriate security architecture needs to be discussed separately, not within the scope of this article.

The. NET application domain (System.AppDomain Class) provides a comprehensive and reliable solution for hosting. NET Plug-ins.

AppDomain has the following powerful features:

A type-safe object in a AppDomain cannot directly access an object in another AppDomain, allowing the host to force a plug-in to be isolated from another plug-in.

AppDomain can be configured separately to allow the host to fine-tune AppDomain for different types of plug-ins by providing different configuration settings.

You can uninstall AppDomain, allowing the host to unload the plug-in and all associated assemblies, except assemblies that are loaded in a domain-neutral manner (using the loader optimization option Loaderoptimization.multidomain or Loaderoptimization.multidomainhost). This feature makes the host process more reliable by allowing the host to unload Plug-ins that failed in managed code.

The main application and the plug-in hosting process can interact with one of the various IPC mechanisms available (for example, COM, named pipes, Windows communication Foundation (WCF), and so on). In the proposed architecture, the role of the main application process is to manage the creation of the composite UI and to provide a variety of application services for Plug-ins. Figure 2 Displays the Bloomberg Launchpad view, which represents this type of composite UI. The "Stealth Analytics" component is created and rendered by the WPF-based Plug-ins hosted by the Bloomberg application portal, and all other components are created and rendered by the Win32-based Bloomberg Terminal application. The main application process sends commands to the plug-in hosting process through the plug-in controller agent.

Figure 2 Sample Composite UI

The plug-in controller is running in the default AppDomain of the plug-in host process, which handles commands received from the main application process, loading the plug-in into a dedicated appdomains and managing its lifetime.

The sample source code provides a reference implementation of the architecture and includes the managed infrastructure as well as the Sapp and DEMO Plug-ins.