Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Minor Upgrades, Transforms and Dialog Boxes

29 views
Skip to first unread message

Steve Moss

unread,
Nov 13, 2003, 10:38:46 AM11/13/03
to
I have authored an MSI package which is a minor upgrade to a previous
version of a product, and apply it with REINSTALL=ALL and
REINSTALLMODE=vomus properties. This works OK, except for a problem
with a dialog box that has been updated in the new vesion. Basically,
the dialog box changes are ignored when running the installation, and
the old dialog box (from the earlier version installation) is dislayed
and processed.

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.

Carolyn Napier [MSFT]

unread,
Dec 2, 2003, 5:45:15 PM12/2/03
to
By including 'v' in the REINSTALLMODE property value, it instructs the Installer
to use the provided package as the package to run from in place of the cached
package. In essence, the Installer will run from the copy provided and will
recache this "new" package in the %windir%\Installer folder.

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...

Steve Moss

unread,
Dec 3, 2003, 4:45:48 AM12/3/03
to
Carolyn:

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?

Carolyn Napier [MSFT]

unread,
Dec 10, 2003, 9:58:39 PM12/10/03
to
The installer engine's order of application is patches first followed by
customization transforms. So a patch cannot update a customization transform
(and primarily the customization transforms were those created by
administrators -- so the ordering makes sense).

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...

Rich [Microsoft Windows Installer MVP]

unread,
Dec 11, 2003, 1:53:38 PM12/11/03
to
[Please do not mail me a copy of your followup]

"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>

Carolyn Napier [MSFT]

unread,
Dec 11, 2003, 3:31:40 PM12/11/03
to
Not necessarily. There are a couple of things to remember about customization
transforms and patches. The MSP uses the transform mechanism for making changes
to the database. In fact, an MSP contains at a minimum a set of transforms (one
being the database authoring transform and one being the patch specific
transform). The database authoring transform is the transform between the target
package and the upgrade package. The patch specific transform is generated by
patchwiz -- it makes a copy of the upgrade package and then adds patch specific
data to it (like the Patch table, PatchPackage table, etc.).

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...

Rich [Microsoft Windows Installer MVP]

unread,
Dec 11, 2003, 4:57:10 PM12/11/03
to
[Please do not mail me a copy of your followup]

"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.

Steve Moss

unread,
Dec 11, 2003, 6:08:36 PM12/11/03
to
Rich:

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.

Carolyn Napier [MSFT]

unread,
Dec 16, 2003, 2:36:51 PM12/16/03
to
If the MSP adds new dialogs that aren't present in the base package or the
language transform, you won't have a problem. It cannot be used however to
modify a control on an existing dialog (any update will fail if it's something
carried by the language transform because it won't be present in the in-memory
view of the database at the time) nor can it be used to remove an existing
dialog if it's only carried in the language transform.

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 [MSFT]

unread,
Dec 16, 2003, 2:39:50 PM12/16/03
to
The sequence in which MSPs and transforms are applied does not prevent any UI
changes from being made by the MSP. It's true that it restricts the changes
(particularly updates to existing data), but you could add new dialogs in the
MSP. It's also possible to author the base package in such a way as to maximize
the UI change capabilities in the MSP. If your language transform consists of
just string changes, then you can still use your MSP to alter the dialog layout,
wizard sequence, and control events since they would be present in the base
package.

- 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...

0 new messages