I think there are several factors to the issue being observed: 1) the PrintUI /dd (delete driver) command does not remove the driver, but in quiet mode 'succeeds', IF there are any 'printers' objects which depend on the driver. They need to be removed first. I use the /dl command after I enumerate all printers and find the names of the printers that are using my driver. Since our application creates 'printers' (printer objects) using the default naming convention of 'MyPrinter', 'MyPrinter (Copy 1)', etc, I rely on the fact that all of my printers start with the same base name and I enumerate the registry keys under HKLM\SYSTEM\CurrentControlSet\Control\Print\Printers to make a list of 'printers' to deleted prior to removing the driver. However if it matters that someone could make a copy and name it 'Anything' then the EnumPrinters api should be used. 2) the PrintUI /dd command does not clean up the entries in the Driver Store. As indicated in this thread it is the default behavior to leave all versions of a driver in the driver store and then prompt the user with a very confusing and useless dialog which asks the user if they prefer oem9.inf or oem??.inf, etc. Prior to using WIX in a non-MSI setup I call the Difx API DriverPackagePreInstall prior to making the call to PrintUI to installing the printer (/if), and then after a call to PrintUI to remove all printers (/dl) and a call to PrintUI to remove the driver (/dd), then we call Difx API DriverPackageUninstall which removes the driver from the Driver Store. You can use 'pnputil -e' (and 'pnputil -f -d oem##.inf') to validate this behavior. You can also use the mmc PrintMgr add-in to validate the PrintUI commands. 3) The PrintUI commands do not have a package update feature. I always call the above uninstall process prior to installing a new version of the driver to avoid the ugly dialog mentioned above.
I am assuming that your driver is a PNP device and that you have some reason for calling the PrintUI to configure the Printer object in a different manner that the default model defined in the INF file. If the INF defines a printer model which is adequate to the situation I would just use the difxApp extension element in the Component which includes the INF file. But as I needed to customize the printer object I found that I could not use the Wix DifxApp extension and also call a PrintUI command as it always results in a failure and a rollback. So I removed the DifxApp extension from my package to get the rest of my PrintUI CAs working. I have yet to address the issue that the driver has not been removed from the driver store, probably by implementing calls to DifxAPI. Phill -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Strange-problem-with-printer-driver-installation-tp7591538p7591565.html Sent from the wix-users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
