I'll try and answer this but it's best to seek some other opinions too. 1. The order of patch installation wont usually matter. When you create a patch, you target it at a particular version or even multiple versions (eg patched/upgraded installations) and MSI works out the right sequence. See the MS patching whitepaper at http://www.microsoft.com/download/en/details.aspx?id=19013 You do this by creating one or more transforms (diffs) with the torch tool and passing them when you create the patch with pyro.
2. The 4th version field of the MSI product version is ignored by Windows installer. You can use it for information but we don't - some APIs will retrieve the 4th field however. We use [major version].[service pack].[build] The files in your installer have no such restrictions. Version those in whatever way suits you. 3. The way we do that currently is to build the patch from administrative installations of the released and updated MSIs instead of using wixpdbs. http://blogs.msdn.com/b/pmarcu/archive/2008/05/30/patching-something-you-didn t-build-with-wix-using-wix-.aspx and other articles in that blog. 4. MSI records what patches are applied to a product. It depends on how you want to retrieve the information. You can use MsiEnumPatches() from C++ for example. You could also install something to act as a marker. Useful links include: MSDN on Windows installer Peter Marcu's blog Heath Stewart's blog Rob Menchsings blog (and others on the Wix team) This mailing list's archives Wix docs -----Original Message----- From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] Sent: 10 January 2012 23:18 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching I am in the process of writing an installer for a company product (we were previously using Installshield). Once, released we will need the produce patches for bug fixes and enhancements. The expectation that these patches will consist of simply updating some of the released files and/or adding new files not part of the initial distribution. I think we will generally do a minor upgrade. In some cases the patches are dependent on a previous patch and in other cases not. Therefore I've been reading material about how we should structure our initial release of the product to best enable but still have some questions about things that aren't clear. Can someone help me here: 1. How can we generate the diff against the installed version for the patches that can be installed in any order. We are not sure what the users machine will have because they may have already applied one of the other patches. Surely we don't need to generate a patch for each possible order of installation of all the patches. 2. We can update the 3rd or 4th component of product version when doing an upgrade/patch for some. Can someone explain the consequences of each option. When we generate a diff for the patch, does the generated patch use the product version and only patch against it or does it only patch products with matching Product GUID and file versions. 3. When creating a patch, I want to explicitly specify the collection of files (DLLs etc.) to be upgraded. I don't want any other existing files to be touched. I have read that when you specify a patch components (i.e. via ComponentRef) inside a PatchFamily element, any components in the same fragment will also be updated. Can I avoid this without having to create different fragments for every component in my product which is a bit of a pain. 4. As far as I can tell, you can always apply a patch (msp) multiple times even if the product is already patched. Is there a way to flag that the patch is already installed without updating the product version. If there are any good sources of material which answer some of these questions, please point them out to me. Thanks in advance sanjay ----------------------------------------------------------------------------- - Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
