2

I have a driver installing using DriverPackageInstall, and uninstall DriverPackageUnInstall in wix installer. It works very well, If install and Uninstall driver version 1.0.0.0.

But when I install 1.0.0.0 and upgrade 1.2.0.0. it works well replaces drivers with 1.2.0.0 binaries.

But when I uninstall, driver is not uninstalled, checked logs found that uninstallation successful DriverPackageUnInstall return 0, also logContext.difxError is also 0.

Not able to figure why driver is not being uninstalled.

 <Custom Action='InstallDriverAction'
         After='InstallFiles'>NOT Installed</Custom>

 <Custom Action='UninstallDriverAction'
         After='InstallInitialize'>
                Installed AND NOT UPGRADINGPRODUCTCODE</Custom>

One observation is driver,cat,inf of version 1.0.0.0 is still present at DRVSTORE, and driver with 1.2.0.0 deleted.

Any help will appreciated.

Thanks

user3664223
  • 305
  • 3
  • 19
  • 1
    You use early sequencing for your major upgrade? And you plan to continue to do so I hope? Please see my comments below. – Stein Åsmul Jul 18 '18 at 00:21
  • Currently I have sequnces After='InstallFiles' and After='InstallInitialize'. I am not sure whether it answers your question. – user3664223 Jul 18 '18 at 12:58
  • Where do you sequence `RemoveExistingProducts`? – Stein Åsmul Jul 18 '18 at 12:59
  • There is no tag RemoveExistingProducts in my .wxs file – user3664223 Jul 18 '18 at 13:03
  • You will find that in your compiled MSI file. Inspect with Orca or an eqivalent tool (`InstallExecuteSequence`). Seeing as the install works you obviously schedule `RemoveExistingProducts` early though. The issue is that this is now a requirement to continue to use, and never schedule it late given how you condition things. Probably OK if your package is small. – Stein Åsmul Jul 18 '18 at 13:06
  • @SteinÅsmul RemoveExistingProducts is early as I can see than my DriverInstall and Uninstall custom actions has higher values than RemoveExistingProducts – user3664223 Jul 18 '18 at 14:51
  • Sounds OK. I have not tested, but I think those conditions will work for a minor upgrade as well, if you decide to use such an upgrade in the future. Late-REP major upgrade will not work - I am pretty sure. With these things the proof is always in the pudding. If you have the time testing would be advisable. – Stein Åsmul Jul 18 '18 at 15:19

1 Answers1

2
 <Custom Action='UninstallDriverAction'
         After='InstallInitialize'>
                Installed AND NOT UPGRADINGPRODUCTCODE</Custom>

The condition looks wrong. It currently says "uninstall the driver if it is installed, except during a major upgrade". You propably want to uninstall the old version of the driver during major upgrade, so the AND NOT UPGRADINGPRODUCTCODE should be removed.

The Installed part of the condition is also wrong. Actually this would uninstall the driver when doing a repair! It could be argued that it can be useful to uninstall the driver and then install it again to hopefully fix some errors. But in its current state, the driver would not be installed again during a repair, because the properties are checked only once at the acquisition phase and won't be updated during the execute phase of the setup.

My suggestion:

 <Custom Action='InstallDriverAction'
         After='InstallFiles'>NOT Installed OR REINSTALL</Custom>

 <Custom Action='UninstallDriverAction'
         After='InstallInitialize'>
                REMOVE~="ALL" OR REINSTALL</Custom>

The first condition is pretty standard: install the driver if it is not already installed OR this is a reinstall (aka repair).

The second condition says to uninstall the driver in any of these cases:

  • During a regular uninstall
  • During an uninstall in the context of a major upgrade. This requires early sequencing for the RemoveExistingProducts standard action so the uninstall of the existing version will be done entirely before installing the new version. When using the WiX MajorUpgrade element the default is Schedule="afterInstallValidate", which does exactly that.
  • During a reinstall (aka repair). I'm not entirely sure yet if that's a good idea, see comments below.
zett42
  • 25,437
  • 3
  • 35
  • 72
  • 1
    Creative! I haven't tested this (no time), but I am wondering if that uninstall action will be triggered in a late-sequenced major upgrade? Wouldn't the old version's uninstall - which then runs **after** the new version's install has completed - run the uninstall action (and also not run the install action) - potentially wiping out the new driver that was installed? (unless the new setup installs a different set of files). Should not be a problem if the uninstall sequencing is early? In that case the old version should be fully gone before the new setup starts its business? – Stein Åsmul Jul 18 '18 at 00:20
  • 1
    I can't remember if it is possible to detect self-repair versus repair with conditioning? And I am not sure it is good that these install / uninstall actions run during self-repair? Something to test maybe. – Stein Åsmul Jul 18 '18 at 00:25
  • 1
    @SteinÅsmul Good points. My suggestion assumes early sequencing for [`RemoveExistingProducts`](https://learn.microsoft.com/en-us/windows/desktop/Msi/removeexistingproducts-action), so the existing version will be completely wiped away before installing the new version. I'm also not sure if my suggestion breaks with self-repair or if its even wise to do so in this context. I will give these some more thoughts and propably edit my post later. – zett42 Jul 18 '18 at 09:32
  • 1
    Should be fine, just as long as the user is aware of it I think. Not sure how many use late-REP-sequencing - it is very complex to get right. Also very hard to give advice with all these exceptions that are involved - so many "moving parts" in MSI. I like to split driver installations to a separate setup / MSI (especially for large products), but that is not without problems either. – Stein Åsmul Jul 18 '18 at 11:21
  • Thanks @zett42 and Stein – user3664223 Jul 18 '18 at 13:00