views:

37

answers:

2

I have created an outlook 2007 add-in project in vs2008, targeting .net 3.5, then migrated the project to vs2010.

I have then published the project from vs2010 to a web site, and installed the add-in using click-once to a virtual machine running xp, .net 3.5 sp1, and outlook 2007. This all works great and I can see my add-in within outlook. Publish update settings are set to update the add-in at startup rather than every 7 days.

However when I then make a simple change to the add-in, update the AssemblyVersion and AssemblyFileVersion of the add-in project, and then publish the updates, when I run outlook it doesn't detect that there is a new version, and just runs the current one that is installed.

I can see that the publish has generated a new setup.exe and added a new folder to the 'Application Files' folder with the current (autogenerated) publish version.

Can anyone suggest how I can get the update to be deployed to the client?

Edit:

I left the VM without outlook running for a while (over lunch) and then came to start it up and it detected the latest update and installed it. However now when I make another change and re-publish it is not picking it up. I wonder if this has something to do with caching of the files. I have deleted all the temporary internet files on the client vm, but that didn't help.

A: 

Double-check and make SURE you have it set to check every time they open the application and not just once a day.

RobinDotNet
Yeah I double and triple checked it, it definitely didn't seem to be limited to once a day. Thanks anyway
Matt
Yeah, I figured, but it was free to ask. You said you are updating the assembly versions -- these are completely irrelevant to ClickOnce. Are you updating the ClickOnce version in the Publish tab of the property pages for the add-in?
RobinDotNet
Yep, I have it set to automatically update the revision, and I also updated the number before the revision just in case... I have only just started to investigate clickonce and it seems to work as I expect if I use it to publish a wpf application, just not with this particular vsto add-in.
Matt
It could be an Office thing. When you close Office, can you check and make sure it's not still running in the processes? This happened to me the last time I had this problem. I was adding my add-in to Outlook, and Outlook wasn't fully closing.
RobinDotNet
I have to say that yesterday I was testing changes to an Outlook Add-In, and in the course of testing, I deployed 56 updates, and every single one of them updated when I opened Outlook. Can you check the version in the default deployment manifest (yourapp.vsto) on your webserver and make sure it's changing? Maybe there's a problem with publishing the files. Are you using VS to publish?
RobinDotNet
You do realize that checking for updates every time they open Outlook will slow down the startup time of Outlook? The ClickOnce team recommends that you not do this unless you are going to put out updates everyday (or multiple times a day).
RobinDotNet
Yeah I know it'll slow down the startup process of outlook, we're taking that into consideration. We are just starting with click-once and I was trying to see the real differences with all the settings. It is strange, because it worked every time with a normal desktop app, it was just not working as I expected for startup updates in OL plugins. I didn't realise I could just open the .vsto manifest file, I'll double check the versions next time I publish the update. Thanks for all your suggestions!
Matt
You're welcome. We have ours checking for updates once a day, which seemed kind of like a compromise. Good luck!
RobinDotNet
A big gap between responses I know, but I've just got back around to working with click-once and the vsto addin. It seems that the addin is always checking for updates on startup, but the iis server looks to be returning an old version for the response. I guess this has something to do with caching on the iis server...
Matt
A: 

The reason it is not detecting published updates was due to iis caching the pages.

I added the expiration common header in IIS7 manager and set it to expire immediately, and after that the addin detected each change as it was published.

Matt