Thanks again Peter. I think I will read the MS whitepaper on patching because it is clear that our current strategy does not fit with the MSI model of updates. We may take the opportunity to change our model as you suggest.
Regards snajay > -----Original Message----- > From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] > Sent: 12 January 2012 10:20 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Patching > > 1. There are a couple of ways that might work for you. It depends if > you have > to stick with your current upgrade strategy or if you have an > opportunity to > alter it. > > Firstly, most people find that producing major upgrade MSIs is by far > the > easiest way to support upgrades. You cant apply these out of order > though. > > This blog post describes your scenario > http://blogs.msdn.com/b/heaths/archive/2006/06/14/cumulative-service- > packs-wi > th-minorupdatetargetrtm.aspx > This also won't allow you to apply patches out of order. You can apply > a > later patch first but, being cumulative, the earlier patch is included. > It > does however simplify the problem of supporting a product with many > possible > combinations of patches involved. > > You could also create patches that target multiple versions of the MSI. > That > fits your requirement better but problem with those is that, if you > produce > many patches that can be applied in any order, the number of possible > installed products that need to be targeted increases rapidly. This > increases > patch size and testing complexity. If the patches are independent and > don't > change the product version, that may not be a problem. > > I believe you could also create small updates that do not alter the > product > version and could be combined freely. As long as all your files are > versioned > and backwards compatible, then you could mix these freely and the MSI > versioning rules would always ensure the highest is installed. > > The number of possible combinations you allow could grow quickly and > will be > inherently tricky to support. Finding the best solution is really only > something you can decide, knowing what your constraints are. Whatever > you > decide on, you should definitely make some test patches. I also > strongly > recommend reading the MS whitepaper. Its long and dry but explains many > ways > in which you can use patching and has some example scenarios too. > > 3. I think heat automatically generates components in fragments unless > you > use the -sfrag switch. > > Torch works with all kinds of files. Windows Installer works best if > your > executable files have a version resource that specifies the file > version but > it'll will handle unversioned binaries too. > > > -----Original Message----- > From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] > Sent: 11 January 2012 23:09 > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] Patching > > 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 > ------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
