upgrade install behavior

[alexzakharov]

hi, i'm observing the following behavior during web-based upgrade update.

- brand-new directory is created under "application data" which will contain the new installer exe
- the directory (under "application data") that contains old installer is NOT deleted.
- the actual old installer exe is NOT deleted
- the old installer's windows update task is NOT deleted

I assume this behavior is by design. Please confirm.

The above also implies that every time I run an upgrade, I need to rerun "/updatesetup" to recreate the windows task. Seems a bit clumsy... or am i missing something?

What is the recommended way of dealing with this:
- how do people cleanup the old installer's directories under "application data" after updgrade is run?
- how do people clean up the obsolete scheduled tasks

Any comments suggestions would be much appreciated

-alex

[MichaelNesmith]

Yes, this is by design.

First, when you uninstall (as part of an auto-upgrade), the directory for the other installer must go away. If it doesn't, this would be an issue with the (Un)Install MSI Setup plug-in.

Second, when you re-install, the scheduled task is re-created with the same name, updating the old scheduled task.

[alexzakharov]

Michael,

I'm not sure I'm following you.

>First, when you uninstall (as part of an auto-upgrade), the directory for >the other installer must go away. If it doesn't, this would be an issue >with the (Un)Install MSI Setup plug-in.

this is my point exactly - i would think that the directory SHOULD go away - but it does NOT (that is why i asked whether the directory NOT going away is InstallAware's behavior by design). i can duplicate this pretty consistenly whether or not i'm doing a web-based upgrade or local drive-based upgrade.

>Second, when you re-install, the scheduled task is re-created with the same name, updating the old scheduled task.

As I pointed out earlier - when I reinstall the scheduled task does NOT go way, nor does it get recreated with the new location of installer. Of course if i run "/updatesetup" manually (after reinstall) then it does get recreated but are are you saying that at the end of the reinstall the task should get recreated AUTOMATICALLY??

Moreover, forgetting about updates - If I install a version of the product, then run "/updatesetup" and then run a simple uninstall (from the shortcut that gets created by default in any IA's project) then the scheduled task does NOT go away. Are you saying it should go away?

[alexzakharov]

OK, so to make this more manageable I posted a separate question as to what happens directories under "application data". I hope that in this thread we can resolve the issue of Scheduled Task.

- The main question is what should happen to an existing Scheduled Task if I run a basic upgrade?

To put it into context - some of our clients want completely unattended upgrades. Thus when they install the product the very first time - they will go through explicit steps of setting up username/password and schedule of the windows task, but from that point on they want updates to happen silently and transparently. So the local administrator would put up an upgrade update pack on a webserver with "silently run installer" checked. then the scheduled task (configured to do automatic promptless download and updates) would detect the new release, download it and install it. silently. Naturally at this point it is of utmost importance as to what happens to windows task? Is it still pointing to old installer? Do I need to run custom code that would silently recreate the windows task by pointing it to the new installer? I dont want to prompt the user for username/password/schedule again - i basically need to reuse all of existing params with exception of installer path. How do I do that? Or does IA already do it for me?

[MichaelNesmith]

Hi Alex,

I'm afraid with the out of the box behavior, you will need to have your users reconfigure the old scheduled task.

Of course, you may change the default scripts to work around this inconvenience.

My suggestions would be as follows:

1) As part of your main setup, create an environment variable. Call this variable, for instance, %MY_UPDATE_EXE%. Have it point to $UNINSTALLLINK$. The command for this is Set Environment.
2) Update the Scheduled Task command to run %MY_UPDATE_EXE%, instead of $UNINSTALLLINK$.

You may update the updates.mia script to fulfill both these tasks. If there is a lot of demand for this feature, we can update the default updates.mia script in the upcoming versions.

[alexzakharov]

Michael,

Thanks - i like your environment idea. Actually yesterday i wrote a trivial command-line (C#) utility which updates the scheduled task and I was going to call it via Run Program at the end of each upgrade... but your idea is a bit cleaner.

Cheers,

Alex

[alexzakharov]

Michael,

Sorry to keep bothering you with this... but it just doesn't seem to work.

I tried your idea of setting environment variable.
I added the following line (right after comment below) in the updatesetup script:

if Variable WIZARD Equals CANCEL
Terminate Installation
else
Set Persistent Variable UPDATE_CONFIGURED to TRUE
Comment: TRY SETTING ENVIRONMENT VARIABLE HERE
Set Environment Variable %TEST_VAR2% to bla2

I tried different settings "always set", "add value to beginning", "set entire variable", "remove during unistall". but no matter what i did after the /updatesetup script completes i dont see that variable in my environment!?

Interestingly I tried adding the same line to main script, right before apply install like this

Set Environment Variable %TEST_VAR% to bla
Apply Install (get result into variable SUCCESS)

And it works! Why cant I set the variable in updatesetup script? Can one only set variables as part of Install?

Notice: I also tried setting/creating variable as part of install (succeded) and then overwriting it during /updatesetup, but even that doesn't seem to work. what is going on here?

Please help.

Alex

[MichaelNesmith]

Purple commands are Windows Installer commands. They execute only when Apply Install is called. So I'd move the code up to the part where Write Registry is used in the update script. This way, the environment variable will be set early on, and will be updated only when an Apply Install executes. Also be sure to record two environment variables - one for all users, and one for "just me" installs, just like the Write Registry samples. You can use the correct value in the actual task scheduling stage.

[alexzakharov]

Michael,

Ah.. OK - now it makes more sense.

So, now as a quick test I set an environment variable (for all users) MYAPP_UNINSTALL everytime I run an install/upgrade, as expected it executes successfully and I see it being updated in windows's environment variables.

That said what exactly should I set the Scheduled Task's "Run Program" value to? Your idea is to have it point to an existing environment variable, but I dont think it gets resolved correctly. For example I tried setting it to
%MYAPP_UNINSTALL% - but when I look at the resulting scheduled task it still shows as %MYAPP_UNINSTALL% as opposed to being resolved to corresponding environment variable.

If I schedule a task by regular windows means (i.e. right click on scheduled tasks -> add task etc) and set "Run" to %MYAPP_UNINSTALL% then when I save the task it is resolved to the underlying correct path. So if after I save the task for the first time - I reopen it I see the path, and no longer see the "%MYAPP_UNINSTALL%" string.

In short - does InstallAware's schedule task command support "Run Program" values which reference windows' environment variables? An if so - how exactly do I set it? Sorry if this is an an obvious question ( I tried %bla%, '%bla%', $bla, $%bla%$). Your documentation says that I can either set it to an actual path or to path including variables defined in installaware script, but nothing about windows environment variables...

Much thanks,

Alex

[MichaelNesmith]

Hi Alex,

I'd expect that the Task Scheduler would correctly resolve the environment variable (which is, after all, a Windows 'system' variable), at the time of starting the scheduled task. Are you saying this is not the case? This would be a most surprising limitation of the Windows Task Scheduler.

[alexzakharov]

Well, believe it or not, regardless of IA, i wasn't able to figure out how to make Windows Task Scheduler to run off an environment variable. It seems that it resolves env vars at creation time, not at runtime, which is odd and annoying.

so, instead (just like everything else in computer science ), i added another layer of indirection by creating a batch file that calls the uninstaller and the batch file DOES rely on environment variable. then windows scheduled task simply calls the batchfile.

The above workaround should work for now.

BUT I REALLY THINK THAT THE NEXT RELEASE OF IA SHOULD OFFER THIS TYPE FUNCTIONALITY BEHIND THE SCENES. Basically - right now IA's web updates with upgrades dont work as a normal user would/should expect, since they dont update the scheduled task. forcing the rerun of /updatesetup every time should not be required, dont you think?

Alex

[MichaelNesmith]

Yes I agree - as you will find out we listen to customer feedback/suggestions/requirements - we'll be expanding the base update script capabilities in line with your expectations during the next update.

[Tinus]

Thanks,

I need the same. Glad to here you are working on it.