cpurick

I realize that the pseudo-ClickOnce publish feature cannot deploy an Outlook app because it can't set CAS or create the necessary registry entries.

So what can it do, with regard to Outlook addins

I envisioned an msi-deployed Outlook addin, with an embedded application manifest that points to a deploy point. The idea is that you run setup once to install your addin, using the "add file" functionality of the setup project to include the application manifest from a previously-published deployment package. The setup program sets CAS and modifies the registry to point to the app manifest. Since the app manifest was actually created with the publish functionality, it actually points to a valid deployment manifest.

Later, when you make any sort of upgrade to your application, you simply publish the new version. The application manifest gets out of sync with the deployment manifest, and -- voila! The loader downloads the current version, and thanks to careful engineering the CAS is still valid for the newly downloaded files.

In practice, however, my addin won't load if I include the application manifest from the deploy point. It will only load if I keep the default application manifest installed by setup. The two manifests are nearly identical, except for the installfrom & codebase stuff which points to a (supposedly) successfully published image of the app.

What's the deal Am I on a wild goose chase Can this be done

I notice that virtually all of the MSDN content on Outlook deployments refers to the setup deployment option. Even the limited references to the publish deployment option don't actually explain how to get the published content onto a workstation.

Does publish actually work for Outlook I'm beginning to think it's one of those features that sounds great on paper, but which doesn't actually work in the wild. Somebody -- anybody -- please tell me I'm wrong.

Rick



Re: Visual Studio Tools for Office Publishing Outlook Addins -- Does Publish Actually Work with Outlook?

McLean Schofield - MSFT

Hello,

I am sorry that you did not get a response sooner. You are correct that publishing Outlook add-ins is of limited use in some scenarios, because it does not create the required registry keys, set the appropriate security policy, or copy the application manifest onto the end user's computer. However, I tested copying the published application manifest to the end user computer (rather than the one that is generated in the \bin directory when you build the solution), and this worked fine for me.

Here's what I did:

1) On my development computer, I created a simple Outlook add-in that displays the message "First add-in" on startup and I built the project.

2) I published the project to a 2nd computer (my "deployment" server for this test).

3) On a 3rd computer (my "end user" computer for this test), I granted myself full trust to the publish directory on the 2nd computer, I copied over the application manifest from the publish directory, and I created the required registry keys, being careful to point the ManifestLocation keys to the local copy of the application manifest. Note that I copied over the application manifest from the publish location, not from the \bin directory on the development computer.

4) I opened Outlook and saw the message as expected.

5) I checked the copy of the application manifest on the end-user computer, and verified that it was the same version at the publish location.

6) On my development computer, I revised the add-in so that it now says "Second add-in", rebuilt the project, and republished it to the same location.

7) On my end-user computer, I opened Outlook and saw the message "Second add-in", as expected.

8) I checked the copy of the application manifest on the end-user computer, and verified that it had been updated to the new version in the OutlookAddin1_1.0.0.1 subfolder of the publish location.

If the application manifest that you are installing in the Setup project isn't working, then I would make sure that the codebase attributes in the manifest file are correctly pointing to the assembly and the deployment manifest in the publish location, and that the ManifestLocation registry keys on the end user computer are pointing to the correct location of the application manifest on the computer.

I hope this helps,

McLean Schofield






Re: Visual Studio Tools for Office Publishing Outlook Addins -- Does Publish Actually Work with Outlook?

bobchauvin

I can verify that this works. I am finding, though, that a VSTO 2005 migrated to VSTO_SE with heavy code may be problematic.

For example, I can create a simple VSTO_SE and deploy ala Click Once using the above method, but with a migrated VSTO add in with code I get errors trying to access office dlls from the deployment server, which is incorrect, as they reside on the local user's desktop.

More to come...