Architecture of Application-Level Add-Ins
Add-ins created by using the Office developer tools in Visual Studio have architectural features that emphasize stability and security, and enable them to work closely with Microsoft Office. This topic describes the following aspects of add-ins:
Understanding add-ins
Components of add-ins
How add-ins work with Microsoft Office applications
Applies to: The information in this topic applies to application-level projects for Microsoft Office 2013 and Microsoft Office 2010. For more information, see Features Available by Office Application and Project Type.
For general information about creating add-ins, see Office Solutions Development Overview and Getting Started Programming Application-Level Add-Ins.
Understanding Add-Ins
When you use the Office developer tools in Visual Studio to build an add-in, you create a managed code assembly that is loaded by a Microsoft Office application. After the assembly is loaded, the add-in can respond to events that are raised in the application (for example, when a user clicks a menu item). The add-in can also call into the object model to automate and extend the application, and it can use any of the classes in the .NET Framework.
The assembly communicates with the application's COM components through the primary interop assembly of the application. For more information, see Office Primary Interop Assemblies and Office Solutions Development Overview.
If multiple add-ins are installed for an application, each add-in is loaded in a different application domain. This means that one add-in that behaves incorrectly cannot cause other add-ins to fail. It also helps to ensure that when the application is closed, all the add-in assemblies are unloaded from memory. For more information about application domains, see Application Domains.
Note
Add-ins that you create by using the Office developer tools in Visual Studio are designed to be used only when the host Microsoft Office application is started by an end user. If the application is started programmatically (for example, by using Automation), the add-in might not work as expected.
Components of Add-Ins
Although the add-in assembly is the main component, there are several other components that play an important role in how Microsoft Office applications discover and load add-ins.
Registry Entries
Microsoft Office applications discover add-ins by looking for a set of registry entries. For a complete list of the registry entries used by add-ins, see Registry Entries for Application-Level Add-Ins.
When you build your solution, Visual Studio creates all of the required registry entries on the development computer so that you can debug and run your add-in. For more information, see Building Office Solutions.
If you use ClickOnce to deploy your solution, the Setup program generated by the publish process automatically creates the registry keys on the end user computer. For more information, see Publishing Office Solutions by Using ClickOnce.
Deployment Manifest and Application Manifest
Add-ins use deployment manifests and application manifests to identify and load the most current version of the add-in assembly. The deployment manifest points to the current application manifest. The application manifest points to the add-in assembly, and specifies the entry point class to execute in the assembly. For more information, see Application and Deployment Manifests in Office Solutions.
Visual Studio Tools for Office Runtime
To run add-ins that are created by using the Office developer tools in Visual Studio, end user computers must have the Visual Studio Tools for Office runtime installed. The runtime includes unmanaged components and a set of managed assemblies. The unmanaged components load the add-in assembly. The managed assemblies provide the object model that your add-in code uses to automate and extend the host application.
For more information, see Visual Studio Tools for Office Runtime Overview.
How Add-ins Work with Microsoft Office Applications
When a user starts a Microsoft Office application, the application uses the deployment manifest and the application manifest to locate and load the most current version of the add-in assembly. The following illustration shows the basic architecture of these add-ins.
Add-in architecture
.png "2007 Office add-in architecture")
Note
In Office solutions that target the .NET Framework 4 or the .NET Framework 4.5, solutions call into the object model of the host application by using PIA type information that is embedded in the solution assembly, instead of calling into the PIA directly. For more information, see Designing and Creating Office Solutions.
Loading Process
The following steps occur when a user starts an application:
The application checks the registry for entries that identify add-ins that were created by using the Office developer tools in Visual Studio.
If the application finds these registry entries, the application loads VSTOEE.dll, which loads VSTOLoader.dll. These are unmanaged DLLs that are the loader components for the Visual Studio 2010 Tools for Office Runtime. For more information, see Visual Studio Tools for Office Runtime Overview.
VSTOLoader.dll loads the .NET Framework and starts the managed portion of the Visual Studio Tools for Office runtime.
The Visual Studio Tools for Office runtime checks for manifest updates, and downloads the most recent application and deployment manifests.
The Visual Studio Tools for Office runtime performs a series of security checks. For more information, see Securing Office Solutions.
If the add-in is trusted to run, the Visual Studio Tools for Office runtime uses the deployment manifest and application manifest to check for assembly updates. If a new version of the assembly is available, the runtime downloads the new version of the assembly to the ClickOnce cache on the client computer. For more information, see Deploying Office Solutions.
The Visual Studio Tools for Office runtime creates a new application domain in which to load the add-in assembly.
The Visual Studio Tools for Office runtime loads the add-in assembly into the application domain.
The Visual Studio Tools for Office runtime calls the RequestComAddInAutomationService method in your add-in, if you have overridden it.
You can optionally override this method to expose an object in your add-in to other Microsoft Office solutions. For more information, see Calling Code in Application-Level Add-ins from Other Office Solutions.
The Visual Studio Tools for Office runtime calls the RequestService method in your add-in, if you have overridden it.
You can optionally override this method to extend a Microsoft Office feature by returning an object that implements an extensibility interface. For more information, see Customizing UI Features By Using Extensibility Interfaces.
Note
The Visual Studio Tools for Office runtime makes separate calls to the RequestService method for each extensibility interface that is supported by the host application. Although the first call to the RequestService method usually happens before the call to the ThisAddIn_Startup method, your add-in should not make any assumptions about when the RequestService method will be called, or how many times it will be called.
The Visual Studio Tools for Office runtime calls the ThisAddIn_Startup method in your add-in. This method is the default event handler for the Startup event. For more information, see Events in Office Projects.
See Also
Concepts
Architecture of Document-Level Customizations
Visual Studio Tools for Office Runtime Overview
Other Resources
Architecture of Office Solutions in Visual Studio