Thank you for your suggestion. We wanted to minimize installation download size so we limited installed language packages to the same languages as the programs are installed in. Sadly this brought us this problem :(
We are currently supporting 12 languages and each language is updated independently - if we update one language, an update would be triggered for all our customers even when they don't use the updated language. Example: Customer is using GEO5 in english and we updated Hungarian localization... In this case we don't want to burden the customer with unnecessary update. Current ideas: 1) Install all languages for shared libraries - PROs: easy to implement - CONs: bigger installation packages need to be downloaded by the customers; need to have much smarter update detection (don't trigger update in unused localization); all our products need to contain shared libraries in all the localizations (currently some products are available in Czech and English only) 2) Require an update for all installed products if conflict is detected - PROs: relatively easy to implement - only conflict detection is required - CONs: updating all the products can be time consuming and could frustrate our customers 3) Create one special "Shared.msi" package installed by all products containing all shared libraries - PROs: downloads, updates and installs only required localizations - CONs: hard to implement - our system needs to be rewritten; needs to do special reference counting for libraries and language usage; must be able to recover from damaged installations (user uninstalls the Product.msi or Shared.msi using command line, but not the other one) 4) Divide our Product.msi features to local parts and shared parts... When installed, bootstrapper checks for required languages and installs shared components in all required languages; when older product is installed, bootstrapper uses the newer product to install updated libraries for the language of the older product - PROs: downloads, updates and installs only required localizations - CONs: all our products need to contain shared libraries in all localizations; installing product with older shared libraries with newer ones in place from other product would be hard, because of the bootstrapper would need to ask the newer product.msi to update the shared libraries to the latest available version - this could trigger full update and could become hell to manage 5) ??? :( something else... I still don't know, which way I'm going to use - 3) seems to be the "best" solution, but hardest to implement... 1) seems to be the easiest one, but requires more download size Ondřej Zarevúcky On 31.5.2010 22:11, Blair 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
