Inconsistant events if canceling from initial upgrade prompt

[tgooderham]

With ISUS 2.1, I have vb code that checks for updates for my product.
I have added prompts at each of the events.

The first time it checks for and finds the update, it fires the OnDownload events.

If I then cancel that installation and re-run, it fires the OnUpdate events, which begins to install the product.

If I cancel from that, it fires the OnDownload again.

This will repeat back and forth.

Can't it simply leave the downloaded app there until it's been installed?

[Chris_Woerner]

Couple of things....

Until the update installation is started, the Update Service leaves the update on the machine. The update could be on the machine for days before it is started.

Once the update installation is started, the update service will remove the update. As a result, if the update is cancelled or fails, the update will be downloaded again.

below is some sample code that uses three calls:

> find updates (Enum)
> download an update (Download)
> install an update (Execute)

You can even do one stage at a time. For example, you could find the update and download it. Post download, prompt the user to install now or install later. So long as you don't call execute, the update will remain on the computer.

-----------

Const pszProductCode = "{E5D5D9E8-178A-4312-B9C0-094442490497}"
Dim UpdateAgent As Agent
Dim UpdateCollection As Updates
Dim WithEvents UpdateInstance As Update

Private Sub CheckForUpdates()
Set UpdateAgent = New Agent

If UpdateAgent.IsConnected Then
Set UpdateCollection = UpdateAgent.EnumUpdates(pszProductCode)
For iIndex = 1 To UpdateCollection.Count
Set UpdateInstance = UpdateCollection.Item(iIndex)
If (UpdateInstance.Download(True) = True) Then
UpdateInstance.Execute
End If
Next
End If

End Sub

Public Sub Form_Load()
CheckForUpdates

End Sub

Private Sub UpdateInstance_OnDownloadBegin()
'MsgBox "OnDownloadBegin"
End Sub

Private Sub UpdateInstance_OnDownloadComplete(ByVal nResultCode As Long)
'MsgBox "OnDownloadComplete"
If nResultCode <> 0 Then
MsgBox UpdateInstance.GetErrorDescription(1)
Else
If MsgBox("An Update has been downloaded, do you want to install?", vbYesNo, "Update Available") = vbYes Then
UpdateInstance.Execute
End If
End If
End Sub

Private Sub UpdateInstance_OnProgressChanged(ByVal nBytes As Long, ByVal nPercent As Long, ByVal strTransferRate As String, ByVal strTimeRemaining As String)
nBytes = Round(nBytes / 1024)
'Write these values to a label in the form
lblStatus.Caption = "Percent complete: " & nPercent & "%" & vbNewLine _
& "Bytes downloaded: " & nBytes & " kb" & vbNewLine _
& "Transfer Rate: " & strTransferRate & vbNewLine _
& "Time left: " & strTimeRemaining
End Sub

Private Sub UpdateInstance_OnUpdateBegin()
'MsgBox "OnUpdateBegin"
End Sub

Private Sub UpdateInstance_OnUpdateComplete(ByVal nResultCode As Long)
'MsgBox "OnUpdateComplete"
End Sub

[tgooderham]

Thanks for the reply Chris...

It there a way to workaround this?

During your onsite, we chatted about our needs requiring that some customers download over a thin wire dial-up that may take quite some time, with 100+ mb download sizes.

If for whatever reason they cancel the installation, or it fails for whatever reason (some min requirement checks don't pass for example), that means it'll attempt to re-download the package again.

That's going to be a heavy price to pay for some of these poeple.

Thanks,
Ty

[Chris_Woerner]

It should be rare that an installation is cancelled or fails, but there is a workaround if you want to be safe.

After the download is complete, you can add code to copy the downloaded update.exe into an archieve folder. That way if the update fails, the update.exe is always there for the customer to manually rerun.

The implementation goes something like this....

use download() to get the update to the machine
use queryvalue() to get the location of the update
copy the update to an archieve folder
call execute

[tgooderham]

I agree that it should be rare, but in fact is not. Most times it's because of disk space limitations. As the package can be upwards around 100mb, it also has to expand it's contents to temp, which can be up to 3 times that. So it may be that at any one time, there is a need for about 4 times the package size in available space.

I'm a little worried about this workaround though...asside from the additional disk space taken up, a copy operation can take valuable CPU cycles away from our users. Trader's in our case, that require the absolute maximum speed at all times while they're trading.
Since all this is all supposed to be happening silently in the background, it can't affect their existing user experience with our software


Ty

[Chris_Woerner]

You could choose to do the copy right before the execution of the installation (not immediately after the download). So right after the user has said "ok, do the update", you copy the file and then start the installation.

[tgooderham]

Where is the information written to, that contains whether or not execute() operation has been run?

Perhaps I could simply clear that information?

[CChong]

This would be a very useful feature for us to.

Our users implement our software on networks where some clients have Internet access and some do not. We have a messed up way of distributing updates. (I would like to re-engineer this someday as new features are added to the service.)

Currently, I build our update as a single executable file. I then ‘wrap’ it into another installer built as a single executable file. When a user checks for updates the update agent downloads and executes the ‘wrapper’ application which deposits the actual update into a location on the network where all participating clients then execute it to get the update.

Being able to download and save the update to a location of my choice and then execute without deleting the file would allow me to eliminate the ‘wrapper.’

[Chris_Woerner]

Maybe I am missing something, but wouldn't this sequence of calls do that for you?

use download() to get the update to the machine
use queryvalue() to get the location of the update
copy the update to an archieve folder
call execute

[tgooderham]

Not sure about Python, but I don't want to worry about copying another package somewhere on the users machine and having to keep track of where it's located and the space it's going to take up.

You implied that once Execute operation has been run, it no longer knows that a package is already downloaded and waiting for install.

[CChong]

hmmmm...

Currently it uses pAgent.AutoUpdate(gcsGUID, True, 1) to see if an update exists, then pAgent.AutoUpdate(gcsGUID, True, 0). I will admit I have not yet spent a lot of time learining all the methods of the agent. Thanks for the heads up!

[CChong]

Which propety would I QueryValue for ? targetDir?

[Chris_Woerner]

No, use...

LocalFileName 12 - Location of a previously downloaded update file.

[CChong]

Thanks, I think I must be out of date. Can't find this in my documentation.