9 replies to this topic

[nvadnais]

Just browsing through InstallScript help file, so I am really new to it.

I am building a Basic MSI but need to manipulate the files I just installed. Should I be looking at InstallScript instead of VB for my custom action? You ever had to run an InstallScript against details of the just processed install (where the script reads the data versus you keying it into the script to match the install; an example would be getting the user's INSTALLDIR instead of the MSI's default)?

Appreciate any help or pointers you can provide! Thanks.

Norman

[Stefan Krueger]

You could use InstallScript or VBScript, whichever you prefer. You can get values from the install by retrieving the property value ;siGetProperty in InstallScript or Session.Property("PropertyName") in VBScript.
Or maybe you don't need to write script code at all. Depending on the InstallShield version you are using, there is built in functionality to modify XML or TXT files.

[nvadnais]

My customization is adjusting the timestamp of the just delivered files (a later project might modify XML files, but I need the timestamp switch right away). I don't see any built-in way to tell MsiExec to set all of the files using UTC; all installed files seem to apply their timestamp as "local time" (current to the local time zone). I need a file installed in New York to be 7:00 AM and Los Angeles to be 4:00 AM if the file in the MSI is marked noon (the noon is UTC).

So what I don't know is how to get the list of installed files out of the MSI tables and where to place my script -- whatever tool I use -- in the sequence of events. VBScript I know, InstallScript I just read about for the first time. I'm mostly hoping to find a tutorial versus a reference guide for how to do this, in case you know of any.

Thanks for the help!

Norman

[Stefan Krueger]

You can get a list of files by reading the File table. However if you also need to know the location you would also have to evaluate the omponent and Directory tables. My article "Using Dual ListBoxes as Replacement for a Multi-Selection ListBox" at http://www.installsi...stBox/index.htm include a VBScript to read data from a table, maybe this can help you getting started.

You should schedule the script as "deferred in system contaxt" (to make sure it has the required permissions) somwhere after InstallFiles and before InstallFinalize in the InstallExecute sequence.

I wasn't aware of the time zone issue and I don't know of a built in solution. Maybe contact Microsoft support to see if this is a known problem.

Out of curiosity: why is it so important to have the file time exactly correct? Does your software use this information? Isn't that a bit fragile?

[nvadnais]

The solution being installed is self-managing, and will provide its own updates through other means. We are a locked-down environment, and all files in question are only accessible to administrators and SYSTEM; similar technology has been working here for seven years. But when the first solution was installed, every file in it was immediately updated because of the "local time" issue (except for the Pacific time zone, where its MSI was built). The new solution is much larger than the original and the network has many more nodes than it did the first time around, so the double traffic load is more of an issue this time.

As for the time thing, just check with any friend in another time zone who has installed something you also installed. All files will be stamped with the same time for both of you (unless one of you installed during DST and the other didn't, then they are one hour off). I really think this is a CAB limit, in that CAB files only store a date and time without a time zone. I believe you get the same thing with ZIP files. If the program grabbing the file doesn't know to process it as UTC, it just passes it to the OS bare (and the OS applies the local time zone).

Lastly, is there any table or internal property which identifies which files were just delivered. We have technicians who often re-run an MSI (install, not repair). Sometimes they delete the bits before rerunning it and sometimes they don't. So the file may be in the MSI but may have already been installed (and therefore already at UTC). That was something I couldn't find in my research, the ability to identify what was just delivered and what was not.

Thanks again for the help!

Norman

[Stefan Krueger]

While there's a table of all the files in the msi, there's no table that specifies which files get actually copied over. This information is in the log file.

[nvadnais]

That was what I saw too, so I am glad I didn't miss anything.

I refactored my plans to handle this a little different. All files from the MSI are going to be delivered with the same date/time stamp. I will look for any delivered files with the timestamp in local time. If I find that, I will adjust the time based off the of the seat's time zone.

Does that sound like a good plan?

Norman

[Stefan Krueger]

More precicely I should have said there is no static table in the MSI file with that information. At runtime, Windows Installer adds temporary columns (and maybe even temporary tables) that might have some useful information. However as far as I know these aren't documented.

Depending on the control you have over the target systems, would it be an option to temporarily switch the system to UTC time zone for the installation?

[nvadnais]

I have a VBScript which does everything I need. I have tested it outside the MSI and hard-coded the two values it needs to operate. Everything works great.

Now I have the task of inserting the VBScript into the MSI and having it run. I don't see any result and don't know how I can debug it. How do I know it called my script? How do I know it made the two Session.Property reads correctly? Can I have the VB write to a log file or the MSI log file?

Thanks for the help and I would be willing to post when all this is figured out.

Norman

[Stefan Krueger]

It might be easxier to pop up a message box for debugging purposes.