What if you choose to eschew the convenience of having customization assemblies deployed to centralized network locations? Perhaps there is no suitable location, or the number of users who will be using your customized document is sufficiently small that rolling out new assemblies to all of their machines is not particularly onerous. You could always stick with the default behavior, where the customization assembly must be in the same directory as the document it customizes.
As discussed at the beginning of this chapter, however, that leads to the inconvenience of having to copy around the associated files every time you move the document itself. The security system imposes an additional inconvenience; if the customization assembly is in the same location as the document, that location must be fully trusted for some reason other than it simply being in the local machine zone.
For these reasons, your users might want the convenience of having one location on their local machine for the customization. That way the customization need not be moved around with the document and only one location need be explicitly trusted.
If no deployment manifest is listed in the embedded application manifest, clearly the VSTO runtime will not be able to resolve the codebase relative to the nonexistent deployment manifest location. Instead, the VSTO runtime will resolve the codebase by taking the path relative to the current document location. Of course, having a relative path to the document again makes it difficult to move the document around without moving the assembly as well. Therefore, it is most likely that the assembly codebase will be an absolute path.
A particularly useful feature when setting the application codebase is that the VSTO runtime will expand any environment variables in the installFrom path. For example, you could set the installFrom path to this:
The VSTO runtime would then replace the named environment variable with the appropriate path on the user's machine.
But how does one go about editing these paths? The application manifest in question is embedded in the document's data island. Fortunately, the VSTO runtime provides a convenient object model for manipulating embedded application manifests; the ServerDocument object which you saw used for manipulating a document's cached data in Chapter 18, "Server Data Scenarios," will come in handy again.
Part One. An Introduction to VSTO
An Introduction to Office Programming
Introduction to Office Solutions
Part Two. Office Programming in .NET
Working with Excel Events
Working with Excel Objects
Working with Word Events
Working with Word Objects
Working with Outlook Events
Working with Outlook Objects
Introduction to InfoPath
Part Three. Office Programming in VSTO
The VSTO Programming Model
Using Windows Forms in VSTO
Working with Actions Pane
Working with Smart Tags in VSTO
VSTO Data Programming
Server Data Scenarios
.NET Code Security
Part Four. Advanced Office Programming
Working with XML in Excel
Working with XML in Word
Developing COM Add-Ins for Word and Excel
Creating Outlook Add-Ins with VSTO