Thanks for the information Peter. Some follow up: 1) In previous versions of our app, we distributed patches to the customer as a set of files in a zip that the customer simply unzips into the application directory. While this isn't ideal (because of the problems associated with uninstalling patches etc.) it is very flexible in that we can distribute any number of patches that are not dependant on each other, and the customer can install and test the features in any order.
For example, If we deliver patch P1 and P2 to the customer in that order, they may decide to install P2 first because it requires a smaller test effort than P1. I'm not sure how I achieve the same using the MSI patching. Let's say we have 3 wixpdb files: mainprod.wixpdb, patch1.wixpdb, patch2.wixpdb. When release Patch1 we use the transform (mainprod->patch1). Then we release patch2 which is not dependant on patch1 so we use the transforms (mainprod->patch2 and patch1->patch2) to generate it. But that wouldn't work if the customer decided to install patch2 first and then patch1 would it? Might be that i'm missing something obvious here! 3) I think I prefer to segment my components into different fragments and use the wixpdb to generate the mappings as doing admin install is a bit of a pain and potentially more error prone for us. Does anyone know if there is an easy way to do this (eg, if I harvest files using heat for my initial release, can it generate a different fragment for each component?). Another question and potential issue I thought of: Most of the files we distribute are binary (PowerBuilder) files. Will torch be able to generate the transform correctly for these? thanks sanjay > -----Original Message----- > From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] > Sent: 11 January 2012 10:49 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Patching > > 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
