InstallAware

Hello!

Really sorry to have to post here again so soon. I have searched but to no avail. Only found this:

viewtopic.php?f=2&t=5602&start=0

Is it possible to update (preferrably through scheduled silent web update) the secondary instances installed similarly to the "Multiple Instances" sample. I need some pointer in the right direction. Would appreciate it a lot.

Regards,

/Dany

Dear Dany,

only the first installed instance of a Multiple Instance installation can be updated ... this is by design with the Windows Installer engine.

Eventually and when using Multiple Instances, you may create a custom script that iterates through registry to obtain the installed instances and then, un-installing those instances first.

Regards

What i can't immediately see is how i'd run the new installer on each instance. So say my previous install (main instance) realizes an update is downloadable. The new install also realizes it is the main instance since NEWINSTANCE is TRUE. I can then choose a branch of action from NEWINSTANCE and the fact that an UPDATE is running. I may have stored the secondary instances TARGETDIRs or something similar using the registry as you suggest. How do i spawn an update for each instance?

Hmm... yes. I think that will be my question. Do you think it would work if i do it after a successful main instance update?

Sorry for being so vague. Debugging installers is by nature a very slow code-compile-test cycle so time just flies!

TIA,

/Dany

I think i'll take a different route after reading up on Transforms at the M$ DN. After thinking hard and reading a lot of MSI Script Code, i need to ask:

In the "updates" script that is automatically inserted into my project when i click to receive updates, at line 37 and 50 the variable $TITLE$ is used. But on lines 41, 54, 67 and 68 the *compiler* variable #TITLE# is used. It looks like there's some rationale behind this choice and before i spend another couple of days i think i would benefit from knowing about it if it is so.

TIA,

/Dany

Dear Dany,

The #TITLE# gets resolved at build time (it's a compiler variable), while $TITLE$ at package Runtime (it's a script variable).

For what concerns the specific cases you reported, the #TITLE# pre-defined compiler variable is used to manage shortcuts and this because the "shortcut name" must be resolved at build time. Otherwise the relative MSI database entry cannot be created.

Hope this helps you.

Regards

FrancescoT wrote:Dear Dany,

The #TITLE# gets resolved at build time (it's a compiler variable), while $TITLE$ at package Runtime (it's a script variable).

Yes, i am completely and utterly aware of that.

FrancescoT wrote:For what concerns the specific cases you reported, the #TITLE# pre-defined compiler variable is used to manage shortcuts and this because the "shortcut name" must be resolved at build time. Otherwise the relative MSI database entry cannot be created.

Hmm... yes, i gleaned he shortcut vs. other. But was not sure. When you type "relative" do you mean "related" perhaps. Otherwise there's another new concept for me.

The "key problem" seems to be the ordering of script items versus the MSI database. Programming MSI code is like looking at stuff at the top and thinking this will only happen on a subsequent / second run and thus these variables are already altered (in case of... oooph). But it's still somewhat tricky to get ones head around.

I see before me one update check and one update shortcut / scheduler entry *per instance*. I only have another 12 hrs left to trial this. And that is not time enough. My install primarily installs services and must remember auto/manual startup plus at updates whether each service was running before or not. So in the end complexity runs at an exponential pace.

Anyway, thanks for your answer. It does clarify things a bit more.

At the momet i'm leaning to splitting the factory update script into two parts to make this work. And the /instancename/ (aka addition to the TITLE) comes after the "user interview" first time. In your samples the instance name is factored out of time and date. That is just viable in a demo / sample setup - not in "real life". Work and insight to come.

I'll keep you posted on my results. Success or no success.

TNX,

/D

Sorry sorry sorry .... you are absolutely right, it should be "related" as you said.

Regards

After a couple of insights and a lot of un-quotable words i now have a setup that can install multiple instances and update them using any URL (what IA calls "Web Updates").

But imagine my absolutely un-quotable words and their multitude when i found the solution to a problem; *sometimes* the updates did not "work". Of course i was checking GUIDs all over the place. Uninstallation and installation was done but the version number remained the same. Turns out that IA /caches/ the downloads in the update script locally!! So i have to change the NAME of the file in the "Download URL" each time i want to put up a new version. Found out when after... yes two days... i fired up a trace on my webserver.

After searching around here i see that IA uses the Explorer way of doing things. But i did not find any pointer on how to disable this caching. What i want is that when i type a version number and an URL into the updates.ini-editor, the software does as i tell it: "This file now upgrades to version 1.7". Now it's like the version numbers are useless because i have to change the filename and thus i have to rename the file either in the "output" box or in the filesystem so there's another step that can go wrong and annoy customers.

Is it possible to disable this caching or connect it to the version number?

TIA,

/Dany

Dear Danny,

all the update process is handled by the related "Update" script file and which is added to the project once the Update feature gets selected.

For what concerns your question, If you have a look at the script code you will see that the relevant part is within the "[Download and Install Updates]" Code Region (line 199).

The script reads (line 242) and writes (line 421) an "installedupdates.dat" file to keep track of the installed updates ... so you may replace or customize the script code that handles such file.

Regards

Thanks! I have of course made modifications to that part. The posts about IE thre me off. I'll look in to that!

/D

FrancescoT wrote:Dear Danny,

all the update process is handled by the related "Update" script file and which is added to the project once the Update feature gets selected.

For what concerns your question, If you have a look at the script code you will see that the relevant part is within the "[Download and Install Updates]" Code Region (line 199).

The script reads (line 242) and writes (line 421) an "installedupdates.dat" file to keep track of the installed updates ... so you may replace or customize the script code that handles such file.

Regards

No, this is not it. Since i update multiple instances i have to transform the updates too. That folder (where the installedupdates.dat file resides) will change anyway from update to update (because of the transform) - at least for secondary instances.

Even if i comment out the line 421 the script will tell the "socket" to download the file, (the line 336 gets executed, and returns SUCESS), but if i use the same filenames between updates the socket cache will skip the download, still delivering the result SUCCESS.

So if i updated 1.0.0 to 1.0.1 using a file called InstallMyProduct.exe and then put up the update to 1.0.2 using the same filename (but different content, a new revision number and version number at the least), since the cached file from update to 1.0.1 remains in the cache, the update will be run but the resulting version will be 1.0.1 and not 1.0.2.

I can see this with a messagebox at line 336 and something fiddler-like on the update server side. I can also change my server to deliver files with the "Cache-control" header at it's most prohibiting, but that would limit the choices of servers so i have not tried that.

The installedupdates.dat, even if i could use it, is not a problem because when the update exe have been downloaded it is copied or renamed to the Version Name (as in the update packs). And it is not the version name that remains constant.

For others who run into this problem, a viable solution can be to append the Download URL with something that changes between versions but the server ignores, like so:


because that will fool the IE cache. How this affects the Web Media Blocks, i have no idea yet. This is of course also not an optimal solution because it also introduces a manual step that provides means for mistakes.

I hope IA will add an option to skip the cache for downloads. Funny thing is that updates.ini seems to be read each time so i'm far from sure that the above reason covers it all and solves the issue.

Regards,

/Dany