6 replies to this topic

[mspa]

I've got a weird problem where I can't find a solution for, not on google and somehow my post on the community forums are not heard. Now I hope that this forum can help me out.

Our project was originally created in InstallShield 9 and we upgraded to InstallShield 11. After this upgrade it isn't possible anymore to install on a Windows 2003 Server platform. After the 'Preparing to install' window, I get the following error:

"Error applying transforms. Verify that the specified transform paths are valid."

The installation compiled by InstallShield 9 installs on Windows 2000, XP and Server 2003. This InstallShield 9 project was then automatically converted to an InstallShield 11 project upon first opening in the InstallShield 11 application. After a new build of this upgraded project, it installs fine on the Windows 2000 and XP platforms, but gives the above error on the Windows 2003 Server platform. There was nothing changed besides the upgrade to InstallShield 11.

What is the problem here? Is there any way I could get more logging information which can clarify the problem?

[Zweitze]

The problem may be the TransformsSecure policy. In Windows 2000 and XP this policy is disabled by default, in Windows 2003 it is enabled by default. Read the on-line help for more information.

I don't know whether it worked on IS 9, but I experienced the same problem on IS 11 with Windows 2003. In my case, the problem was the multi-language installation. This is implemented by transforms, where setup.exe determines the language and starts installation with the corresponding transform (its the MST file). Unfortunately, setup.exe started the installation with an unsecure transform.

If this is your case: the easiest workaround is leaving the multilanguage setup. In my case this wasn't possible and I ended up writing an alternative setup.exe which applies transforms in the correct way.

[mspa]

Thanks for the reply,

This is indeed also my problem. When I set the TransformsSecure policy in the registry of my Windows 2003 Server, my installation works fine.

However it is not possible to ask our customers to 'hack' their registry just to install our product. MSDN describes the possiblity to set the TRANSFORMSSECURE property in an installation package, which should do the same but for that package only. However when I set this property in my installation to 0, it still doesn't work.

Any pointers in why this property doesn't work? off course I checked my spelling several times

@Zweitze: What did you do to make your alternate setup.exe to work with unsecure transforms and is it hard to do? or some pointers to information about this?

Edited by mspa, 25 January 2006 - 11:03.

[Zweitze]

I gave the property the value "1" and the error went away, but with a twist: the language transform was no longer applied!

The issue is the following: when InstallShields' setup.exe starts you package for (say) the Dutch language, it issues the command:
Msiexec.exe /i <SourceDir>YourProduct.msi TRANSFORMS=<SourceDir>1043.MST

This command is the textbook example of an unsecure transform. The command should have been:

Msiexec.exe /i <SourceDir>YourProduct.msi TRANSFORMS=@1043.MST

Notice the @, that's what it takes to make the transform secure - plus leaving out the path to the .mst. (You may wonder how adding an extra character on the command-line contributes to extra security. If you do find out, let me know, I don't have a clue...)

I tried many things to trick InstallShields' setup.exe into a better command-line, but found nothing. In the end I decided to write my own Setup.exe. Note that this program has some extra tasks, eg. check the version of the Windows Installer engine, install Windows Installer if necessary, reboot if required, etc.

An alternative I recently discovered is using embedded transforms. This site has a contribution that describes an undocumented feature of Msiexec.exe, in certain conditions an embedded transform is always applied. Check that out first.

[Stefan Krueger]

The @ adds security because the user cannot specify a (potentially malicious) transform at a random path, but is forced to use the transform (by the administrator for instance) that was provided with the .msi file at the same location.

I'm not sure if there's a difference between InstallShield versions here, but there is a difference between MSi 1.1 and MSI 2/3

[mspa]

[Stefan Krueger]