a1) In theory, using new WiX patching you can simply exclude components containing binaries that you don't want to patch from the list of components to patch. This list is child of PatchFamily WiX element. If using 'old' patchwiz.dll-based patching (i.e. WiX PatchCreation element) you can use ProtectFile element to (presumably) not path the file. In practice (AFAIAC) I never got new WiX patching to work and I haven't tried using ProtectFile. There is no some ProtectFile table (or its equivalent) in MSI so this appears to be WiX addition to patching process. What works for me is 'classic' PatchCreation approach with WholeFilesOnly='no' so that binaries updated just as the result of the build process contribute minimally to the patch size.
a2) If CA is conditioned on NOT Installed (or NOT PATCH) it won't execute during patch application. a3) You can change MSI in many different ways that don't involve adding or deleting files and patch would transform target MSI database to an updated one. But some changes won't work as you may 'naively' expect them to. Say that you decided that one of your files should, from now on, be read only. Even if that is a change in one of MSI database column values, MSI won't go and change the attribute of your file on disk during patch application. As another example you won't be able to patch only some parts of the Registry and not the other or change a Registry value without using CA made to run during that patch application. These are all MSI-specific issues unrelated to WiX. a4) That is what I would expect. In practice I haven't detected any differences using one or the other update method, but I have been concentrating only on binaries. For ex. signed exe gets patched to an updated signed exe just fine. Hope this helps. -----Original Message----- From: Robert O'Brien [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2008 5:00 PM To: 'wix-users@lists.sourceforge.net' Subject: [WiX-users] "small updates" or "minor upgrades" msi's andassociated msp's We have a v1.0 service deliverable where all aspects of installing the service on any given node are encapsulated in the msi. As you might expect with a service deliverable in addition to use of standard issue wix provisioning steps it also required a sequencing in few CustomActions using WixCA CAQuietExec. We now have a update to a single dll to put out there into the multiple environments where the service is deployed, e.g. beta, preproduction, uat and production. I've read through the Wix Tutorial Lesson 4 Upgrades and modularization (http://www.tramontana.co.hu/wix/lesson4.php) to get insights in to options and how to go about this that have led to some questions. q1 - if we create a "small updates" or "minor upgrades" version of our v1.0 msi to address clean installs and when I run it on a system with an existing v1.0 install in place what special steps should I do in order to have just the single dll replacement to happen and not replacement of all the other dll's that in terms of there major.minor.build.revision assemblyFileInfo settings will have build.revision changes as a side effect of running a complete new build of all our bits to get an new build of the single dll we care about and the msi containing it? q2 - if we create a "small updates" or "minor upgrades" version of our v1.0 msi to address clean installs and when I run it on a system with an existing v1.0 install in place what special steps should I do in order to have just the single dll replacement to happen and not carry out any of the CustomActions using WixCA CAQuietExec that won't be needed in case of an upgrade scenario. q3 - if we create a "small updates" or "minor upgrades" version of our v1.0 msi and an associated msp build output is an msp process inherently constrained to just file updates and removals and nothing else? q4 - if we create a "small updates" or "minor upgrades" version of our v1.0 msi and an associated msp build output is an msp process inherently going to leave any system where it has run looking the same as if we ran the updated msi in upgrade mode? Thanks in advance for any insights and tips on these issues. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
