The passphrase is "Install already": A new look at VSTO Security.

re: The passphrase is "Install already": A new look at VSTO Security.

Kris Makey - MSFT — Fri, 29 Feb 2008 00:28:03 GMT

I'm not quite sure what you mean by "standard installer" but this might help, if not let me know.

Office 2003 in VS 2008 still works under the old deployment/Security model of MSI + CASPOL. You still need to follow the same steps for deploying customizations built against the 2003 version of Office. (When you installed VS 2008 you should have 2 VSTO Runtimes, the VSTO 2 SE runtime and the VSTO 3.0 Runtime)

If you tried to create a manifest against this runtime, the manifests were not signed. VSTO 2 used a flavor of ClickOnce that was built for VSTO. It wasn't until VS 2008 (and Office 2007) that we were able to integrate into the "standard" model of ClickOnce with signed manifests.

However...

If you are just considering customizing Office 2007, then yes you can ignore CASPOL and you can easily build the bootstrapper. By default when you publish using the publish page, a (standard) bootstrapper (setup.exe) that includes the prerequisites(by default: windows installer 3.1, the 3.5 .NET Framework and the VSTO 3.0 runtime ) is created. If you go to the Project Publish Properties page and click the Prerequisites button you can select any prerequistes you want including and custom prerequisites that you make (just like in a MSI Setup project).

In VSTO 3.0 there is no dependancy on the setup project like there was in VSTO 2.0 and 2.0 SE. We expect that in most cases the developer should not need to create it (though you can still create a standard MSI installer, more on this later). VSTO 3.0 Manifests are created and signed automatically when you build the solution and are required even for "F5". The bootstrapper doesn't really have any direct relationship to the manifest. The way the bootstrapper starts the VSTO Click Once install is to call VSTOInstaller with the path to the manifest.

If you wanted to create an MSI installer (with a setup project) you would still have a (standard) bootstrapper and would have to do one of the following:

Publish/copy the (publish contents) manifest and application folder contents to a (known) accessable location (you could publish to an internet or network location in which case the MSI would not need the manifest and etc.) and then use VSTOInstaller to start the customization install.

OR you could include the build folder contents into the MSI manually, register the (addin) (or recustomize the document to point to the local location of the .vsto file) withe the |vstolocal tag. This bypasses the ClickOnce install but not the security (in fact security is evaluated every time you run instead just when an update is installed).

Clear as mud.

Anyway, if that's not enough information, let me know what it is you're trying to do an I'll try and give you some clearer advice.

re: The passphrase is "Install already": A new look at VSTO Security.

Tarquin Vaughan-Scott — Thu, 28 Feb 2008 11:41:45 GMT

Hi, Ive just managed to get ClickOnce working with Office 2007 and an application level Excel add-in. Now I need to create an installer for Office 2003 applications. I have an existing install using VSTO 2 SE and CASPOL - generally works OK. Moving to VS 2008 can I now exclude the CASPOL stuff and rather use VSTO 3.0. If I do so, I understand I need to sign the manifest for trust. Can I creat a standard setup and deployment project and include VSTO 3.0 as a pre-requisite or must I use the publish function as with ClickOnce (my confusion results in that I dont know how the standard setup project creates and signs manifests. Thanks.

re: The passphrase is "Install already": A new look at VSTO Security.

Kris Makey - MSFT — Tue, 22 Jan 2008 03:12:55 GMT

I've been thinking about this a little bit. If you do decide to employ late binding and push your assemblies into the cache, you will need to determine at runtime where that is. Here's what I would use (based on investigation by a co-worker)

System.AppDomain.CurrentDomain.BaseDirectory

re: The passphrase is "Install already": A new look at VSTO Security.

Kris Makey - MSFT — Thu, 17 Jan 2008 21:29:29 GMT

One way to approach this scenario is to bundle all of your indirectly referenced Assemblies into a MSI and author the MSI into a prerequisite package. This works well if you don't think the assemblies you are binding to are going to be updated (or you can live with a different update story for them).

However there is another way.

You can add the Assembly directly to the VSTO project as a "Content" file. As long as you select "Copy Always" the file should get copied into the Build Folder and should be published. In this scenario your indirectly referenced assemblies always end up in the ClickOnce cache next to your VSTO Assemblies. At that point your assemblies also fall under the ClickOnce updating model (rollback/updates/etc work as normal in ClickOnce, version parity is maintained).

ClickOnce Publication with VSTO v3

GQAdonis — Thu, 17 Jan 2008 19:25:34 GMT

I have a question regarding the situation where an assembly that must be shipped with an add-in or document extension is not directly referenced as a dependency. This would occur, for instance, if one wishes to decide dynamically what assembly to load to perform some function (as with using an Abstract Factory) based on runtime conditional logic.

It does not seem possible to assure that assemblies not directly referenced end up in the manifest to be downloaded via the publication feature in Visual Studio 2008.

Do you have any thoughts on how to address this scenario?