views:

274

answers:

1

We have a WPF application deployed using ClickOnce which checks for and performs updates programmatically on application startup. This generally behaves perfectly except for the case where the user chooses "No" to our "Do you wish to update?" prompt. In this case, the next time the user launches the application (consistently) the ClickOnce framework's "Update Available" dialog launches with the option to update or skip. This doesn't cause a technical problem but will be confusing to the user to potentially see two completely differently styled dialogs. (If the user chooses Skip to the ClickOnce dialog then the application then launches and renders our own "Update Available" dialog). Any ideas why the ClickOnce framework dialog is showing in this case? Thanks.

+1  A: 

In the Updates dialog (which is in the Publish tab), do you have the boxes unchecked for checking for updates?

[EDIT 6/18/2010] Here's some more information that I think will fix your problem.

The CheckForUpdate() and CheckForDetailedUpdate() methods persist the results of the update check to disk.  The next time the application runs, the ClickOnce mechanism sees that an update is available and prompts the user with the unwanted window.  

Apparently the update is a two step process.  Step 1 - Check the deployment location for updates and persist the information about what it finds to the local ClickOnce update cache.  Step 2 - Check the local ClickOnce update cache and prompt the user with the update window if there an update is indicated. Unchecking "The application should check for updates" option seems to only cause ClickOnce to skip step 1.  Step 2 still occurs.  

The CheckForUpdate() and CheckForDetailedUpdate() methods have the same effect as step 1 - the data is persisted to disk, so the next time the application is run, Step 2 sees the update and displays the update window.  

The trick is prevent CheckForUpdate() and CheckForDetailedUpdate() from persisting this information to disk.  This can be done by using the parametered overload (CheckForDetailedUpdate(persistUpdateCheckResult)) and set the parameter to false (CheckForUpdate(false) or CheckForDetailedUpdate(false)).

RobinDotNet
We're not using Visual Studio to publish, I've set up an automated publish using MSBuild. The GenerateDeploymentManifest task specifies Install="true", UpdateEnabled="false", and doesn't specify UpdateMode, which should be irrelevant in this case. Thanks.
Tom Hall
Okay, got it. I keep seeing this reported (same w/Visual Studio). I'll see if I can recreate it, and see if I can recreate it. If I can, I'll file a bug on it and talk to the ClickOnce product team aobut it. I'll report back...
RobinDotNet
Hi Robin, did you manage to replicate this? Is it a bug in ClickOnce? If there's a workaround we'd really like to implement it before go-live. Thanks.
Tom Hall
Hi, I reported this to the ClickOnce team, and they are supposed to check it out. I got an e-mail back from the runtime guys on Friday that they haven't forgotten, they're just snowed under right this minute. Do you have a small project that replicates this? Could you file a bug in Connect and attach the project and post the link? If you can do that, I will badger them about it. I mean, remind them about it. ;-) http://connect.microsoft.com/VisualStudio
RobinDotNet
Thanks. I've submitted a bug with a test project attached: https://connect.microsoft.com/VisualStudio/feedback/details/561515/clickonce-application-configured-to-perform-updates-programmatically-launches-clickonce-update-prompt-after-user-cancels-programmatic-update
Tom Hall
Ok, I'll send them the link. They did respond, and asked what version of the .NET Framework are you targeting/installing as a prerequisite. Is it .NET 3.5 SP-1? They seem to think this problem was fixed in that version of the Framework.
RobinDotNet
Hi, yes we are targeting .NET 3.5 and we are packaging .NET 3.5 SP1 as a prerequisite. This is definitely the framework installed on all the PCs where this occurs. Thanks.
Tom Hall
Hi Robin, Microsoft haven't updated the status of my Connect bug yet. Please are you able to follow this up with them? Many thanks.
Tom Hall
I did get some more information, and have posted it above. Can you see if that fixes your problem?
RobinDotNet
Many thanks Robin, that has indeed done the trick. However this is still a bug isn't it? I mean isn't the setting for programmatic updates reflected in the manifest, and if so shouldn't ClickOnce simply never show its own update dialog? Cheers.
Tom Hall
I wouldn't call it a bug, since there is an option for you to tell it not to persist the update check. Some people might want to ask the user if he wants an update, but if he turns it down, force it to install the next time the user runs the application. If you wanted to let him turn it down once (in case he's in the middle of something) but not the next time, this is the best way to accomplish this. OTW you'd have to keep track of 'has he turned it down before...'.
RobinDotNet