The approach suggested by Blair makes the most sense, if the files are in the package already just install *all* files and update a registry setting to indicate the desired MUI... alternatively automatically load based desired MUI based on the current locale.
On Tue, Jun 1, 2010 at 6:11 AM, Blair <os...@live.com> wrote: > Would it be problematic to simply always install all the languages and simply > let the runtime pick the appropriate one each time it runs (based on the > user's language setting, perhaps)? > > Alternately, you would need to check the installed features of the previous > product (either in your bootstrapper or in your MSI) and add all already > installed features to the ones you selected. > > -----Original Message----- > From: Ondrej Zarevucky [mailto:ondrej.zarevu...@fine.cz] > Sent: Monday, May 31, 2010 2:24 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] How to update shared MUI libraries in a consistent > state? > > Hi, > thank you for your reply, I'm sorry for my confusing question - I wanted > to make it more simple, but doing so it lost its clarity. > > My real problem is with our MUI-like solution... I hope other people > solved similar problem with their localization system (MUI?) :-) > > We have a shared library FXPrint.dll with its localization files: > - FXPrint.dll -- handles Print Preview and Print Setup dialogs > in our products > - FXPrint_EN.dll - contains English localization > - FXPrint_CS.dll - contains Czech localization > - FXPrint_ES.dll - sontains Spanish localization > > When user installs our first product in English, only FXPrint.dll and > FXPrint_EN.dll get installed - both in version 1.4. > > But then the user installs our another product in Czech, which now > contains all four files in version 1.5. Because the product is in Czech, > it updates FXPrint.dll and installs FXPrint_CS.dll. > > The result is: > FXPrint.dll v1.5, refcount = 2 > FXPrint_CS.dll v1.5, refcount = 1 > FXPrint_EN.dll v1.4!!, refcount = 1 - not compatible with v1.5 > > All our products are installed using MSI with one language independent > feature and many language dependent features: > Product_Core: > - Product.exe > - FXPrint.dll > Product_CS: > - Product_CS.dll > - FXPrint_CS.dll > Product_EN: > - Product_EN.dll > - FXPrint_EN.dll > ... > > When we run installation, we use our own bootstrapper application, which > calls Windows Installer: > MsiInstallProduct("TRUSS4.msi", "ADDLOCAL=TRUSS4_Core,TRUSS4_CS"); -- > does installation of Czech version and doesn't install any English libraries > MsiInstallProduct("GEO5.msi", "ADDLOCAL=GEO5_Core,GEO5_EN"); -- does > installation of English version and doesn't install any Czech libraries > > If the installations user is using were created at different time, the > shared libraries versions doesn't match and the older product fails to > work properly :( > > Ho do you solve this MUI problem in your products? How do you install > both localization libraries in the newest version available? > > Few notes: > 1) All our products contain localization files in each language - so > both TRUSS4.msi and GEO5.msi can install CS and EN files in their version > 2) We cannot anticipate all our future products or installations so > product testing is not a feasible solution > > My current best idea seems to be to create another "Shared.msi" package, > which contains shared libraires and updates them in a consistent state > (products would ask our bootstrapper to install the required ones). > Sadly this solution is losing reference counting feature from Windows > Installer and we would have to do our own reference counting :( > > Thank you for your help > Ondrej Zarevucky > > On 29.5.2010 0:28, Blair wrote: >> Unless you are using MSI 5.0 or higher, any/all files must be in the package >> involved in the installation transaction. So, the general rule would be to >> include SharedAdvanced.dll in both installations, but condition the >> component containing it to only install if the second package is (or is >> being) installed. >> >> -----Original Message----- >> From: Ondrej Zarevucky [mailto:ondrej.zarevu...@fine.cz] >> Sent: Friday, May 28, 2010 8:00 AM >> To: General discussion for Windows Installer XML toolset. >> Subject: [WiX-users] How to update shared libraries in a consistent state? >> >> Hi everybody, >> we've just encountered a problem with our WiX setup when using shared >> libraries. We have two installations: >> - first one is installing only one shared component "SharedBase.dll" >> - second one is installing two shared components "SharedBase.dll" and >> "SharedAdvanced.dll" >> >> The issue is, when user installs the second program first and then >> installs the first one in a newer version. The updated SharedBase.dll is >> expecting updated SharedAdvanced.dll, but it stayed in the old version. >> >> Is there a way we can update SharedAdvanced.dll library in the first >> installation if it was already installed in the previous installation? >> We don't want to install this advanced library, when there was no >> library present... >> >> The reverse operation is even worse: Installing newer product with newer >> SharedBase.dll and then installing older second product with older >> SharedAdvanced.dll - I don't know, how to solve this at all :( >> >> BTW: Both shared libraries are backwards compatible, but they need to be >> in similar versions for them to communicate. >> >> Thank for any ideas >> Ondřej Zarevúcky >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> > > ------------------------------------------------------------------------------ > > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------------ > > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
