Some background information to this:
1. The package has been authored as a multi-language installer, using
InstallShield.
2. A language transform is applied to the main .msi on installation.
The language transform includes all the dialog box controls, etc., in
the Dialog, Control, ControlCondition and ControlEvent tables (i.e.,
these tables are all empty in the base .msi, and are populated during
the transform).
3. In the new package, I have made changes to one of the dialog boxes
(by adding new text labels, and adding conditions to hide/show the
correct controls according to selected property values), and these are
in the new .mst transform file (I can verify this using Orca).
So, why do the dialog box changes not take effect when running the new
.msi package?
Is MSI using the old dialog box from the cached .msi? If so, how can I
force it to use the new one instead?
--
Regards,
Steve Moss,
CoCo Systems Ltd.
However, the Installer won't update the transform. It will only use the
transform that was registered. There is no native support for applying a
transform post initial installation and the Installer doesn't have an option to
recache transforms.
The transform that the Installer is using for the product can be determined by
using the wilstprd.vbs script in the Windows Installer SDK. Simply run:
wilstprd.vbs {product code} p
And it will output the various product properties. For example, a simple package
plus transform that I created shows the following:
C:\test>WiLstPrd.vbs {BAE98781-CF88-4309-8E2D-3D8B347F5B53} p
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
ProductCode = {BAE98781-CF88-4309-8E2D-3D8B347F5B53}
Language = 1033
ProductName = Simple (TRANSFORMED) Test
PackageCode = {0D71A5BE-7EB8-487D-96C1-22450D5D2470}
Transforms =
*26*Microsoft\Installer\{BAE98781-CF88-4309-8E2D-3D8B347F5B53}\simple.mst
AssignmentType = 0
PackageName = simple.msi
InstalledProductName = Simple (TRANSFORMED) Test
VersionString = 1.00.0000
RegCompany = Microsoft
RegOwner = Carolyn Napier
ProductID = 12345-679-1111111-43760
InstallSource = c:\scratch\simple\target\
InstallDate = 20031202
Publisher = Microsoft Corporation
LocalPackage = c:\WINDOWS\Installer\a1d7a9.msi
HelpLink = http://www.microsoft.com/management
In the example, my transform is cached in my AppData folder. If the dialog
changes you made are only found in the transform, then that is probably why you
don't see your changes. If the new dialog was contained within the package you
are recaching, then it should be reflected in the UI.
Hope this helps,
- Carolyn Napier
Microsoft Windows Installer Team
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
MSI FAQ:
<http://www.microsoft.com/windows2000/community/centers/management/msi_faq.mspx>
"Steve Moss" <nos...@coco.dot.co.dot.uk> wrote in message
news:%23bNx6wf...@TK2MSFTNGP11.phx.gbl...
Thanks for your response. Yes, I had since determined that the
underlying problem is that MSI patches cannot update (or apply)
transforms. This seems to me a serious limitation in MSI patching when
authoring multi-lingual setup projects. Here, all the user interface
elements (and some Directory, Registry, etc., table entries) are
necessarily contained in transforms and applied at installation time,
and therefore cannot be updated via patches.
Do Microsoft have any plans you know of to remedy this in MSI 3.0?
You are correct in that this limits creating multi-language setup UIs where the
setup UI that is displayed is configured based upon the user's language and is
accomplished using a language transform. There are currently no plans to enhance
multi-language UI experience in MSI 3.0. This is under consideration in post MSI
3.0. In any case, I'll forward this information onto the MSI product planning
team.
- Carolyn
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
MSI FAQ:
<http://www.microsoft.com/windows2000/community/centers/management/msi_faq.mspx>
"Steve Moss" <nos...@coco.dot.co.dot.uk> wrote in message
news:e6nN8IYu...@TK2MSFTNGP09.phx.gbl...
"Carolyn Napier [MSFT]" <cna...@online.microsoft.com> spake the secret code
<#z3coK5v...@TK2MSFTNGP09.phx.gbl> thusly:
>You are correct in that this limits creating multi-language setup UIs where
>the
>setup UI that is displayed is configured based upon the user's language and is
>accomplished using a language transform.
So if I understand this correctly, if the patch changes the UI dialogs
and/or controls, then the language transform will fail?
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
Pilgrimage: Utah's annual demoparty
<http://pilgrimage.scene.org>
Customization transforms by necessity of their application order must have loose
transform validation conditions. This is so that the transform remains
applicable even as the product changes (maybe via a minor update service package
that bumps the ProductVersion).
Transforms are simply a binary format with a series of opcodes that describe the
changes to make. Most transforms also include error suppression conditions
(especially when dealing with those from MSPs) to suppress errors like updating
a row that doesn't exist or attempting to add a row that already exists.
So, depending on the types of changes made by the patch transform and the error
suppression conditions, you generally shouldn't have any problem. However, when
two transforms update the same data element to two different values, the last
transform always wins. Thus, if both the patch and the language transform were
attempting to update the same column, the language transform's value would be
the one that wins since it's the "last write".
The implication is that you can't really use a patch to modify values from the
language transform due to the sequencing of the two. This doesn't necessarily
imply that the language transform is invalid and can't be used.
- Carolyn Napier
Microsoft Windows Installer Team
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
MSI FAQ:
<http://www.microsoft.com/windows2000/community/centers/management/msi_faq.mspx>
"Rich [Microsoft Windows Installer MVP]" <legaliz...@mail.xmission.com>
wrote in message news:OynsXgBw...@tk2msftngp13.phx.gbl...
"Carolyn Napier [MSFT]" <cna...@online.microsoft.com> spake the secret code
<eZtbQZCw...@tk2msftngp13.phx.gbl> thusly:
>The implication is that you can't really use a patch to modify values from the
>language transform due to the sequencing of the two. This doesn't necessarily
>imply that the language transform is invalid and can't be used.
OK, so let me restate what you've said to make sure I understand it.
Say I have a localized setup created with InstallShield developer.
This generates a base MSI, a setup.exe and a bunch of
language-specific MST files.
My understanding is that the setup.exe identifies the language in use
on the machine, applies the language-specific MST to the MSI and then
launches the install.
So if we have a patch MSP that we apply, its transform will be applied
the to base MSI and then the language transform MST will be applied on
top of that.
What I don't understand is what happens when the MSP removes or adds
new UI dialogs?
In this scenario should we avoid patching alltogether and just go with
a new installation package?
At this point I don't expect our MSI UI to change much, if any, but I
want to be prepared for the consequences.
This is in fact the issue which caused me to start this thread. In this
scenario (which is the one I have), bear in mind that the MSP patch
creation is based on differencing the two MSI files (and data files) of
the two product versions concerned, i.e., the base MSIs have not had
language transforms applied, and so do not even contain data in the
Dialog, Control tables, etc.
So, any UI changes between the two versions will not even make their
way into the MSP. Data file changes will, though, as will custom action
changes, etc. So, the patch will work fine provided it is not necessary
to change UI-specifics.
If my understanding is correct, the only effective way to patch
multi-language setups will be to change the whole way in which MSP
patches are generated and applied to include, essentially, transforms
to the language transform MSTs. Then, at patch apply time, Windows
Installer will need (a) access to the original, un-transformed MSI, (b)
access to the original language transform applied, and then to (c)
apply a patch transform to the language MST, (d) apply a patch
transform to the original MSI and, finally, (e) apply the patched
language transform to the patched MSI before performing the reinstall.
The MSP will only be able to add new dialogs or control elements or update
anything in the existing in-memory MSI package view (which may include already
applied patches). Anything that is carried specifically by the language
transform is not updatable by the MSP.
One way to approach this is to author the dialog and wizard layout into the base
package and only use the language transform for adding the text string data.
This means that your MSP can update the layout (modify height, width, etc.), add
new control events but could not alter the text that was displayed. It could add
a new dialog as well without a problem. Because the MSP can't affect the
language transform, you'd need to make sure that the text was localized
correctly from the beginning since you would be unable to change it.
- Carolyn Napier
Microsoft Windows Installer Team
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
MSI FAQ:
<http://www.microsoft.com/windows2000/community/centers/management/msi_faq.mspx>
"Rich [Microsoft Windows Installer MVP]" <legaliz...@mail.xmission.com>
wrote in message news:uSZN7GDw...@TK2MSFTNGP09.phx.gbl...
- Carolyn Napier
Microsoft Windows Installer Team
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
MSI FAQ:
<http://www.microsoft.com/windows2000/community/centers/management/msi_faq.mspx>
"Steve Moss" <nos...@coco.dot.co.dot.uk> wrote in message
news:OFxv1uDw...@tk2msftngp13.phx.gbl...