Windows installer musings

[Rhys Smith]

Caveat to everything below and anything else I say in the future about MSIs - I still consider myself a well meaning amateur and no more than that when it comes to MSIs...


On 22 Aug 2014, at 10:54, Rod Widdowson <rdw at steadingsoftware.com> wrote:

> Thanks Rhys,
> Warning it's dangerous to show too much WiX/Msi Installer knowledge…..

It’s certainly dangerous for one’s mental health to *have* too much MSI installer knowledge. I swear the windows installer process is more complex than the Apollo programme.


> 
>>>> What I would like the upgrade to do is rename the existing conf to
>>>> conf.old or conf-v2 or whatever, and then selectively create or copy
> files
>>>> over into the new conf/
>>> 
>>> That I'd like - I hope I can pull it off..
>> 
>> Should be easy enough to do using CustomActions that call VBScript (a.k.a.
> the
>> WiX get out of jail free card).
> 
> Right - As I mentioned earlier I'd prefer writing it in CPP, but that’s not
> going to happen.  Do you happen to have an example of calling MsiSetProperty
> from VbScript I can plagiarize^H^H^H^H^H^H research?  That might make a
> bunch of stuff easier.

I think I played with it a long time ago, but ended up not using it in my WiX config so I’m scrabbling arounds in the depths of my memory here… But I think you just set properties using the session object, e.g.

Session.Property("MSI_SUCKS")="1" 



> An alternative is CAQuietExec...
> 
> The issue that worries me is making it happen at the correct time in the
> right execute sequence (which in turn means I remember what was the issue
> that bugging me when I wrote that throw away line).  I’ll probably start
> with it between “RemoveFiles” and before “InstallFiles” in the "deferred"
> sequence.

Definitely in the deferred sequence.

Hmm, where you schedule this stuff all somewhat depends on where your RemoveExistingProducts happens, and whether the config files got there in the first place from the MSI or from scripting that copied the files there (so that they aren’t under MSI control). 

I did something slightly weird with the Raptor MSIs - I have REP scheduled afterInstallExecute, which installs the upgrade on top of the old one then REP removes anything (under control of the MSI) that used to exist in the old version but doesn’t in the new version. My VBScript to backup config files before I overwrote them selectively was then scheduled after InstallInitialize, but only when the MSI knew it was upgrading (which was an ordeal in of itself). It works for me, but only because I had a particular requirement that that worked nicely for (but I can’t now remember what that was…).

Assuming you’re going with the normal REP after afterInstallValidate, then if the config files were put there by the MSI I think you might need to do this copying/renaming before RemoveExistingProducts - otherwise, of course, the MSI will remove them before you can copy them. If the config files were put there by scripting, however,then they won’t get removed so that’s not an issue.

As for copying files back, if the config files are under MSI control then you might have to run that action after InstallFiles to let it install the stock versions and then overwrite them (if it’ll let you). If they’re not under MSI control then between RemoveFiles and InstallFiles might be okay.

It’s all a bit of a black art really.

As ever with MSIs, you can either go look up numerous docs on MSDN that make little sense unless you’re in “the zone”, or you can try it and see what happens :-). I had a set of very simple MSI packages that I used just to confirm or deny the theories I came up with about the best way to do things. /lv log.txt on msiexec is very useful for figuring out what the hell is going on… And put plenty of logging in the VBScript as well!



> Then of course you need to register the correct unwind function
> and make it happen correctly – I always have to derive the “&feature=3”,
> “!feature”, “?component”, “$component” syntax from first principals, but I
> should be able to avoid that in this case and just consult a NOT [property].
> It’s not hard, but it requires reaching that zen-like state of understanding
> the Windows Installer and writing the code before you fall out of it….

Absolutely… The only way I ever got to grips to any degree with MSIs was to just spend a few days on them doing nothing else. You spend a while remembering everything, get the job done, then instantly your brain rebels and forgets most of the knowledge. Rinse and repeat.


> 
>> If you do end up needing to edit XML files in WiX, that’s fairly easy if
> you’re just changing the values within named elements, using util:XmlFile.
> 
> That would also be useful (for things like adding to services.xml), Now I
> wonder who could help with the XPATH stuff:-)
> 

I have various examples of using util:XmlFile in my config that I can point you at if you end up doing this, including setting stuff in the XML to values taken from the UI. It’s all pretty simple actually - about the only thing in WiX that is!

Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet, the UK's research and education network

email: smith at cardiff.ac.uk / rhys.smith at ja.net
GPG: 0x4638C985