Application and Deployment Manifests

A VSTO solution consists of a document that is linked to an assembly. This enables you to easily update solutions distributed to your users in the enterprise. By contrast, VBA code is embedded in the document, so you distribute the document by making a copy of the code for each copy of the document. This makes it almost impossible to update the code if a bug or security vulnerability is discovered.

Using VBA and Word, you could use a global template containing VBA code that is available to any open document. To update this global template code, you must do one of two things. You either deploy an updated template to each user machine, or, if the template is stored on a server, you must ensure that each user has closed any document that is based on that template before you update the template code.

In the VSTO model, you can deploy the assembly to a share and then e-mail the document to your users. To update the solution, you can deploy the updated assembly to the server; all your end users get the updated code automatically the next time they open the document. You can even roll back to a previous version if something goes wrong with your update.

Application and deployment manifests enable automatic updating and rollback. VSTO uses XML manifest files that are similar to ClickOnce manifest files. ClickOnce is an update and deployment technology used by the .NET Framework. This version of VSTO does not use ClickOnce but is conceptually very similar. Let's look at how manifests work in VSTO. An application manifest tells VSTO which assembly to load and where it is located. The application manifest, which is embedded in the Word or Excel document, also points to a deployment manifest. The deployment manifest is normally deployed to a server and contains a pointer to the current version of the application manifest on the server.

Loading the correct version of your application involves a series of steps that starts when you open your VSTO document. The VSTO runtime reads the location of the deployment manifest from the application manifest embedded in the document. Next, the runtime compares the version of the application manifest with the version of the application manifest pointed to by the deployment manifest. If the two do not match, the new application manifest is downloaded and replaces the application manifest in the document. After the runtime ensures that you have the correct manifest, it reads the location of the assembly from the embedded application manifest, which may have just been updated, and loads the assembly. Your solution is now running. This process is illustrated in Figure 11.10.

Figure 11.10. Manifest-based update model
0 0

Post a comment