Architecture of VSTO Add-ins
VSTO 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 VSTO Add-ins:
Applies to: The information in this topic applies to VSTO add-in projects. For more information, see Features Available by Office Application and Project Type.
When you use the Office developer tools in Visual Studio to build an VSTO Add-in, you create a managed code assembly that is loaded by a Microsoft Office application. After the assembly is loaded, the VSTO Add-in can respond to events that are raised in the application (for example, when a user clicks a menu item). The VSTO 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 (VSTO).
If multiple VSTO Add-ins are installed for an application, each VSTO Add-in is loaded in a different application domain. This means that one VSTO Add-in that behaves incorrectly cannot cause other VSTO Add-ins to fail. It also helps to ensure that when the application is closed, all the VSTO Add-in assemblies are unloaded from memory. For more information about application domains, see Application Domains.
VSTO 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 VSTO Add-in might not work as expected.
Although the VSTO 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 VSTO Add-ins.
Microsoft Office applications discover VSTO Add-ins by looking for a set of registry entries. For a complete list of the registry entries used by VSTO Add-ins, see Registry Entries for VSTO 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 VSTO 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 Deploying an Office Solution by Using ClickOnce.
Deployment Manifest and Application Manifest
VSTO Add-ins use deployment manifests and application manifests to identify and load the most current version of the VSTO Add-in assembly. The deployment manifest points to the current application manifest. The application manifest points to the VSTO 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 VSTO 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 VSTO Add-in assembly. The managed assemblies provide the object model that your VSTO Add-in code uses to automate and extend the host application.
For more information, see Visual Studio Tools for Office Runtime Overview.
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 VSTO Add-in assembly. The following illustration shows the basic architecture of these VSTO Add-ins.
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.
The following steps occur when a user starts an application:
The application checks the registry for entries that identify VSTO 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 VSTO 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 an Office Solution.
The Visual Studio Tools for Office runtime creates a new application domain in which to load the VSTO Add-in assembly.
The Visual Studio Tools for Office runtime loads the VSTO Add-in assembly into the application domain.
The Visual Studio Tools for Office runtime calls the RequestComAddInAutomationService method in your VSTO Add-in, if you have overridden it.
You can optionally override this method to expose an object in your VSTO Add-in to other Microsoft Office solutions. For more information, see Calling Code in VSTO Add-ins from Other Office Solutions.
The Visual Studio Tools for Office runtime calls the RequestService method in your VSTO 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.
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 VSTO 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 VSTO Add-in. This method is the default event handler for the Startup event. For more information, see Events in Office Projects.