ClickOnce Question - How to turn off all automatic application upd

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We would like to control the ClickOnce update (to see if the actual installed
version needs to be updated (customer dependent)), therefore we have
unchecked the “The application should check for updates†on the update page
under publish for the project properties.

But, if we, from our application, checks for a new update (by calling
ApplicationDeployment.CurrentDeployment.CheckForUpdateAsync() and ….) and
there is a new update, but we do not want to download it (the user says no,
or we do not offer the update). The application will offer the update next
time it is started (via the standard clickOnce update window).

Is there any way to turn of that check (which comes after we have checked
for a new version)?

Is it something with the deployment manifest – and can we change in the
manifest on the client (and where is it placed?)?

Can we simulate a click on the ‘skip’-button on the standard update window?

Regards
Bo Hauch
Jens Pontoppidan
 
The behavior below is currently the way ClickOnce is designed and there is no
way to simulate the exact skip behavior you are lookign for. I do however
think there is enough flexibility in the clickonce model for you to be able
to provide your app users the right experience using it

The APIs are currently designed optimized around the scenario where App
developers do not want to own the update prompt UI. They check for updates
using their own update logic but are happy to have the user just be prompted
on next launch of the app by ClickOnce.

What lot of Applications also do is download the update silenty in the
brackground using a background thread and prompt the user later that an
update has been downloaded and that they just need to restart the app to get
it. Orjust not prompt at all and the user just gets the update on Next launch
of the App - th ewhoel update is trnasparent to the user.

The above solutions do not work for applications which are never shut down,
but in that case the App can own the update prompting dialog and the
clickonce prompt is not an issue for the App is rarely relaunched.

Another reason why we cannot let the App control the prompting experience
completely is that if an Required Update is detected we have to update the
App on next launch. We cannot have the not so well designed App actually
prompt a user for a required Update and then accept "No" as an answer and
skip the update.

We basically wanted App to not have to own the Update prompting UI.

Hopefully this gives you a better idea of our thinkign behind our design. We
will defintely be working on making it even more flexible in our future
releases ...

Saurabh
 
Thank you for the answer - we now know that our complete needs not are
covered by the ClickOnce API, but we will make do with what it does.

We have a product in different brandings and with a license which gives the
customer different support/upgrade etc.
Therefore we would like to control all the update proces, including the
'Skip update', because we then could evaluate if the customer actually should
have the new update.

Instead we will make a lot of different download sites, so we have the
customers downloading/updating according to the brand/licens etc. That will
give us some more administrative work.

We still believe that the possibility to programatically skip an update
would make a lot of sense, so we are looking forward to that (and other
Click-Once improvements like more consistency in what mage does and what the
GUI does) in the future.

Regards
Bo Hauch
Jens Pontoppidan
 
Back
Top