One-Shot customizations, but we're not VBA.

Last week I had the pleasure of getting some very interesting feedback from some of the Microsoft Office development audience (people who develop against office through VSTO/VSTA/VBA/Shared Add-ins/etc ).  If you were at said event and are now reading here because of it, I welcome you and hope you enjoy the time you spend.

One of the more interesting things of note I heard was that VSTO just wasn't as easy and simple to deploy for those one-shot customizations that might be created to solve a small problem, save some time or simply just do something repetitious quicker.

Certainly this is entirely true under the older Security model, CASPOL is not something you just "simply do" and move on, it takes a fairly significant degree of initial investment and understanding of .NET to get to the "working" state.  Click-Once can also seem like it's a little too heavy-weight for a similar reason, there's all this extra stuff to consider:  prerequisites, updating, a publishing location, certificates. 

This is why I'm going to talk about the "tricks" you can use for that simple once-off git 'er done solution.  These methods are supported they are not considered our prime scenarios used in this particular context.

First Let's talk about publishing versus building.  If you are creating a customized document, you might consider bypassing publishing, although if you're creating application level customization (something that will impact multiple documents) then I fully recommend publishing even for these quick and dirty solutions.  There are still some things you can do to make things simple and quick with the publishing experience in add-ins.  I will come back to add-ins and publishing after I cover documents.

Documents!

What the Developer needs to do:

1. Copy (or email) the entire contents of the bin/release folder over to the "user", Zipping the folder is perfectly acceptable.
2. Inform your user about the "Trust Prompt" (see below)
3. Inform your user about that moving the document around without moving the customization files can cause the customization to stop working.

What your user needs to do:

1. Keep folder contents together (document must be in the same folder as .vsto, .dll.manifest and .dll file)
2. Click the "Install" prompt when the document is opened.  (This is just asking for Trust)
   (note:  The right part of image just shows "vstolocal" the user doesn't need to be aware it)
3. "Un-install" can be achieved by deleting the document and customization files, though you should know that it does leave the trust decision behind (a single registry key).

Incremental improvements towards more "professional" level solutions that you can do:

1. (Developer Action) Acquire a proper (verifiable by Certificate Authority) code-signing Certificate from a well-known Trusted Root Authority and Sign you manifests with it instead of using VS generated Self-Certificates.  This changes the information in the "Trust Prompt" from 'unknown publisher" to "<YourName on certificate>":
   
2. Have your user install your "proper" certificate into their trusted publisher list. By having your user trust you as a publisher, they will no longer be prompted to install the solutions you sign with your certificate.
   1. (Developer Action) Export your Signing Certificate without the Private key (I use Certmgr.msc in windows vista here in this example)
      
   2. (Developer Action) Send your public-key-containing exported certificate file to your Customer. 
   3. (User Action) Double-click the Certificate file to start the install process.
   4. (User Action) Click "Install Certificate"
   5. (User Action) Select "Place all certificates in the following store" and Choose "Trusted Publishers"
3. Re-Customize the Document to look for the manifest file in a specific location.  If you do this, then the document can be moved around but the .vsto/.dll.manifest/.dll files must stay in one (specific) location.  You can do this with Office my manually editing the custom properties as shown in this image:
   

Add-ins.

Inherently there is a more work to do since you need to somehow "hook-up" the add-in to the hosting (Office) application.  Fortunately for you, we've thought through this scenario.  Here are the steps to the quickest "simple" setup.

What the developer needs to do:

1. Set the Publish Location to "publish", this will put the final add-in files in the project/publish folder.
2. Set the Updates to Never, because you will not be providing and update framework.
3. Click Publish
   
4. Copy the publish folder contents to a zip folder or disk.
5. Inform your user about the "Trust Prompt" (see document example).
6. Inform your user that they must un-install using Add-Remove Programs, but can delete the "setup" files after installation.

What the user needs to do:

1. Run Setup.exe (if you think they may not have the .NET runtime or VSTO Runtime) OR you can have them double-click the vsto file from their end (CD,un-zip folder, etc)
2. Click the "Install" prompt when it comes up.
3. Use Add-Remove-Programs if they need to un-install.

Incremental improvements towards more "professional" level solutions that you can do:

1. (Developer Action) Acquire a "proper" code-signing Certificate from a well-known Trusted Root Authority  and Sign you manifests with it instead.  This changes the information in the "Trust Prompt" from 'unknown publisher" to "<YourName on certificate>" (See the document example of this)
2. (User Action) Install your "proper" certificate into their trusted publisher list. By having your user trust you as a publisher, they will no longer be prompted to install the solutions you sign with your certificate.  (See the document example of this)
3. (Developer Action) Deploy the Add-in via CD and as long as it is run from the same drive as the original install on that computer, updates can be achieved in the same manner as a "normal" install.

These are the easiest 2 "throw-away" solution deployment methods that I can think of.  There are so many advantages to using VSTO you shouldn't feel blocked by the belief that deployment must always be Click-Once with large amounts of infrastructure.  There are ways to wrangle it to manage scenarios beyond the initial "deploy via server and provide constant updates" model that Click-Once specifically targets well.

With that I'll wrap this up with a final side-note.  I wrote the bulk of this post a week early because next week I will be on a boat most likely not thinking about anything other than having fun and looking at scenery.  I may or may not have a post due to this trip, but it's possible I might have just enough of a backlog to work something out.

Thank You for Reading.

Kris

 

[note:  Edited 5-19-2008, Attempting to clarify what is done by user versus developer]