ClickOnce: ApplicationDeployment.Update() doesn't reset ApplicationDeployment.IsFirstRun - by Taz0

Status : 


Sign in
to vote
ID 505070 Comments
Status Active Workarounds
Type Bug Repros 1
Opened 10/28/2009 8:04:58 AM
Access Restriction Public


If you have deployed a ClickOnce application, and have successfully updated it programmatically using ApplicationDeployment.CurrentDeployment.Update() (i.e. it returns true), then restart the application using System.Windows.Forms.Application.Restart(), the old version of the application shuts down, then the new version of the application starts up, but the value of ApplicationDeployment.CurrentDeployment.IsFirstRun is false (which causes ApplicationSettingsBase.Upgrade() to never get called).
Sign in to post a comment.
Posted by Microsoft on 10/20/2011 at 2:27 PM
Thank you for your improvement suggestion. After careful review, we’ve determined that this suggestion doesn’t meet our triage bar for our next release. However, we may review it again in the future if similar suggestions arise. Thank you!
Posted by Microsoft on 10/20/2011 at 2:24 PM
Thank you for your improvement suggestion. After careful review, we’ve determined that this suggestion doesn’t meet our triage bar for our next release. However, we may review it again in the future if similar suggestions arise. Thank you!
Posted by Taz0 on 9/24/2010 at 1:58 AM
Has this been fixed in VS2010? The status of this issue is still "Active".
Posted by Taz0 on 11/11/2009 at 12:13 PM
Glad I could help. This is indeed a low-priority bug since it's an edge case and there's a very simple workaround - add a "IsFirstRun" flag to the user settings file and default it to True, then on application startup test it, and if it's True, manually call ApplicationSettingsBase.Upgrde() and set it to False inside the override of Upgrade().
Posted by Microsoft on 11/11/2009 at 11:19 AM
Allon, thanks for taking time to post the detailed repro steps. I have been able to repro the bug. I am currently busy with a higher priority bug at this time. However I want to assure you that this bug has been enqueued in my bug list and I will be getting to the bottom of this issue as soon as poosible. Thanks for being patient. I will keep you updated.

Software Development Engineer, ClickOnce
Posted by Taz0 on 11/10/2009 at 11:12 AM
When I first tried to repro it using a small test solution, I also got the same results as you, Akshat. But then I remembered the special circumstances that were present with my project - we had to move the deployment location to a different path and wanted users to have a seamless transition without uninstalling the application (and losing their settings). So I just replaced the old .application with the new one, which has the new deploymentProvider URL, and all users were updated to the new publish location automatically.

When publishing to a local folder, for some reason the deploymentProvider element is not added to the application manifest, even for projects targeted for .NET 2.0 which don't support the omission of the deploymentProvider element (but that's a separate issue). So if you publish your new version to a different folder, and copy over the new application manifest and overwrite the old one, the update will fail (since it uses relative paths).

So in order to repro you need to publish version 1 to location X then install and run it. Now publish version 2 to location Y, and use MageUI to check the "Include Start Location" checkbox and set the start location to the *full* path of location Y (this step is not needed if you publish to a HTTP or FTP location). Save it using the auto generated pfx. Then copy over the corrected .application file from location Y and overwrite the .application file in location X (both manifests should now point to location Y). Now run the application, which should still launch in version 1, and perform a programmatic update (which should look at the manifest at location X, see that the deploymentProvider URL has change, then be redirected to location Y). After the application restarts, IsFirstRun will be false. So this bug only occurs when the deploymentProvider URL changes ("codeBase" attribute). Sorry for the wrong repro steps on the original issue.

If you still can't repro using the above steps, I'll send you my repro solution.
Posted by Taz0 on 11/10/2009 at 10:11 AM
This was a WinForms application targeted at .NET 2.0 running on Windows Vista SP2 with .NET 3.5 SP1 installed (built using VS2008 SP1) so I believe it was using 2.0 SP1 versions of assemblies in the GAC. This issue might have already been solved in .NET 4.0. I was able to reproduce it consistently with my application, but I will attempt to create a standalone repro solution and upload it here within a week, so please don't close the issue in the meantime. Thanks.
Posted by Microsoft on 11/10/2009 at 9:56 AM
Hello allon_g,

Thanks for submitting this bug. I have been trying to repro the bug on my machine with the repro steps that you provided. However in my case the value returned by ApplicationDeployment.CurrentDeployment.IsFirstRun is True both in the case of a fresh install and the first launch after an update is published. I am running this on 32 bit Windows 7 machine with.Net 4.0 Beta 2 release build installed.

Can you provide me more information on the OS and the version of .NET are you using? Did you try to do this on more than one machine. If yes, does the same error occur on both the machines? If it reproes just on one machine do you remember doing anything typical on that machine (For example installed/ uninstalled different versions of .NET or system restore). Also I would appreciate any other details that you can provide to repro this bug.

Software Development Engineer, ClickOnce
Posted by Microsoft on 11/3/2009 at 3:15 AM
Thanks for your feedback.

We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.
These specialized experts will follow-up with your issue.
Posted by Microsoft on 10/29/2009 at 5:05 AM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(