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
