Getting started (GUID and auto-check)

Good afternoon,I'm evaluating wyBuild/wyUpdate...

The application we're looking to perform auto-update is provided in different "flavours" (OEM versions) to different people. I guess these then need different GUID's - so that they're recorded separately? I tried to do that using #if... but the GUID has to be set at design-time? Am I off-beam here?[at least one person will want all the flavours installed so he can use them at the same time; quite possible...]

Then auto-check; ideally we'd like to know that this happened on a specific day of the week (!) - that is we'd appreciate the update check being on a Monday morning. New releases happen over the weekend... Now that would mean a Friday install would check the next Monday, then a week later etc. If the application not used on the Monday then it'd check on the Tuesday... Is this a bit far-fetched or something we could do?

Thanks,Dr Michael DyeDyetech

Opps; should have read forum *properly* first - the OEM/version question has (just) already been asked... Ah, well, means two people thinking along the same lines...

Out of interest - where is the "last checked" date/time stored? And (feature request) would it be possible to read this from the control (so one could say "Last successful check for updates was at 12:35 on 1/Jun/2010" or whatever).

[I'm expecting the laptops with this software on to not always be connected to the internet]

Thanks,Dr Michael Dye

Hey Michael,

Good afternoon,I'm evaluating wyBuild/wyUpdate...

The application we're looking to perform auto-update is provided in different "flavours" (OEM versions) to different people. I guess these then need different GUID's - so that they're recorded separately? I tried to do that using #if... but the GUID has to be set at design-time? Am I off-beam here?[at least one person will want all the flavours installed so he can use them at the same time; quite possible...]

Sure, this is possible. You'll need to create the AutomaticUpdater manually. Simple paste some variation of the code below directly below the call to the "InitializeComponent();" in your form's constructor.

AutomaticUpdater automaticUpdater = new AutomaticUpdater();


// setup the AutomaticUpdater propertiesautomaticUpdater.Anchor = ((System.Windows.Forms.AnchorStyles)((System.Windows.Forms.AnchorStyles.Top | System.Windows.Forms.AnchorStyles.Right)));automaticUpdater.Location = new System.Drawing.Point(338, 12);automaticUpdater.MenuItem = this.mnuCheckUpdates;automaticUpdater.Size = new System.Drawing.Size(16, 16);automaticUpdater.TabIndex = 3;automaticUpdater.ClosingAborted += new System.EventHandler(this.automaticUpdater_ClosingAborted);


// required property - set the container as the FormautomaticUpdater.ContainerForm = this;




//TODO: setup your #IFs here.automaticUpdater.GUID = "d4fca505-567e-4079-944c-e51ef7872058";




// add the control and finalize AutomaticUpdater controlthis.Controls.Add(automaticUpdater);((System.ComponentModel.ISupportInitialize)(automaticUpdater)).EndInit();
Then auto-check; ideally we'd like to know that this happened on a specific day of the week (!) - that is we'd appreciate the update check being on a Monday morning. New releases happen over the weekend... Now that would mean a Friday install would check the next Monday, then a week later etc. If the application not used on the Monday then it'd check on the Tuesday... Is this a bit far-fetched or something we could do?

Well, you could set "DaysBetweenChecks" property to 7. This will check for updates every week. Would this work for you?

Out of interest - where is the "last checked" date/time stored? And (feature request) would it be possible to read this from the control (so one could say "Last successful check for updates was at 12:35 on 1/Jun/2010" or whatever).

That's a good idea, we'll add that property to the next update of AutomaticUpdater.

Evening Wyatt,

Thanks for the quick reply. I understand the "manual creation" of the control until the release later this year that'll let you fiddle with some of the background stuff (reading the post to Omaer). No problems with that approach.

As for the "check every 7 days"; not quite the same as "check every Tuesday or as soon as possible thereafter" but I was being picky...

We've now run some tests and got good results; except for one oddity - when the application restarts after an upgrade ("Restart now") then the application command line appears to have some strange 'garbage' on it - and this is interpreted as a filename (part of the way the app works) (args[0] from Main()) - does that ring any bells? (it appears to be part of the executable path, or the users path?)

Thanks,Dr Michael Dye

We've now run some tests and got good results; except for one oddity - when the application restarts after an upgrade ("Restart now") then the application command line appears to have some strange 'garbage' on it - and this is interpreted as a filename (part of the way the app works) (args[0] from Main()) - does that ring any bells? (it appears to be part of the executable path, or the users path?)

No, I've never seen that. Can you paste the garbage. Also paste the expected result.

Morning Wyatt,

OK; added some debug info to capture the args passed to main():

[STAThread]public static void Main(string[] args)

And this is what was caught after an update (then choosing restart now):

arg[0] = Files\MyCompanyarg[1] = Ltd\MyProgram\MyProgram.exe

Given that there's spaces in the path this seems to be parts ofC:\Program Files\MyCompany Ltd\MyProgram\MyProgram.exe

We treat the first arg as a filename for opening (which indeed it is via a file association) - this works

So my best guess is the command line generated by WyUpdate as it restarts the application after updating it isn't enclosed in quotes and Windows is both running the application then providing some of the command line as args???

Thanks!Dr Michael Dye

PS Found a property: this.autoUpdate.LastCheckDate - seems to contain the last (successful) check date?

[STAThread]public static void Main(string[] args)

And this is what was caught after an update (then choosing restart now):

arg[0] = Files\MyCompanyarg[1] = Ltd\MyProgram\MyProgram.exe

Given that there's spaces in the path this seems to be parts ofC:\Program Files\MyCompany Ltd\MyProgram\MyProgram.exe

We treat the first arg as a filename for opening (which indeed it is via a file association) - this works

So my best guess is the command line generated by WyUpdate as it restarts the application after updating it isn't enclosed in quotes and Windows is both running the application then providing some of the command line as args???

That's odd - we'll check this out.

Found a property: this.autoUpdate.LastCheckDate - seems to contain the last (successful) check date?

Oops - yes, we already have the last checked property. I had overlooked it when I was scanning the property list. This property will give you the last successful update check. It doesn't count failed update checks.