Skinned dialogs in patch creation

[Snoopstah]

Hi

I am trying to prepare a skinned installation for a patch install

The patch install is displaying the dialogs without skin. They are large sized dialogs looking like they are scaled for skins, but the skin is missing and it's just an oversized grey box.

The orginal installation was prepared with the Blue Skin.

Anybody knows whats the problem and any suggestions to prepare a skinned patch installation ?


If however I place the previous installation CDImage (the one to be patched) back in the location that it was installed from (the cdrom drive), the patch install displays the correct skin.

Must be looking for the skin images in the original source image setup.isn file???
How can I fix this?

[joshstechnij]

This issue was originally reported on work order IOC-000066894, which should be resolved for InstallShield 2009. If you log the patch installation with update.exe /verbose"C:\Path\LogFile.log", there should be some information contained regarding where the InstallScript engine is looking for the skin file and whether or not the skin could be found (there should be a line in the log that reads something similar to "Skin path for patch install: " along with a path).

[Snoopstah]

The log file shows two lines related to the skin:

InstallShield 9:29:34: Could not find setup.ini where expected (C:\Documents and Settings\Test\Desktop\install\cdimage). Defaulting to skin file setup.skn
InstallShield 9:29:34: Not using skins for this installation. Could not find skin file C:\Documents and Settings\Test\Desktop\install\cdimage\setup.isn.

This is what I meant by the patch seems to require the initial CDIMAGE to be in it's original location to use a skin in the patch. Surely this can't be true?

I have just realised we are still using InstallShield 2008. So if the bug has been fixed in IS 2009, then I may have a case to convince our management to fork out the $$$ for an upgrade !!!!!

[Snoopstah]

I installed an eval version of InstallShield 2010 to test the skinned dialog in a patch install.

Major release 2.6 is built in InstallShield 2008. This is installed on a test machine from C:\Documents and Settings\Test\Desktop\install\cdimage\setup.exe
Patch release 2.6.x (update.exe) is built in InstallShield 2010. This is installed from "d:\Update.exe" /verbose"D:\install.log"

when I run the upgrade.exe I still have the same issue with an unskinned dialog for the patch installation. The log file shows:

InstallShield 15:01:17: Could not find setup.ini where expected (C:\Documents and Settings\Test\Desktop\install\cdimage\). Defaulting to skin file setup.skn
InstallShield 15:01:17: Not using skins for this installation. Could not find skin file C:\Documents and Settings\Test\Desktop\install\cdimage\setup.isn.

[joshstechnij]

Can you attach the full log file?

[Snoopstah]

Find attached the install.log (I didn't bother proceeding with the actual install past the welcome screen.)

[joshstechnij]

This issue is still occurring because the patch is running with the IS 2008 version of ISSetup.dll (version 14):

InstallShield 8:46:35: InstallShield Install driver started, version:14.0.162.0

If the patch was built in the Patch Design view in IS 2010, but both the base and upgraded MSIs were built by IS 2008, this would explain why the older version of the engine is still being used (the patch build consumes a built copy of ISSetup.dll from the latest setup).

To get the IS 2010 version of ISSetup.dll (version 16) in the patch, the upgraded (latest) MSI package needs to be built in IS 2010.

[Snoopstah]

OK, so what have I done wrong.

I installed InstallShield 2010 Premier edition EVAL on a vmware machine
I copied my previous InstallShield 2008 project to that machine.
I converted the project (automatically offered by installshield 2010)
I did a full build of the project (version 2.6.29.0)
I then created a patch through Patch Design.
Pointed Latest1 to my just built 2.6.29.0 version
Pointed Previous1 to my already release InstallShield 2008 install 2.6.27.0
Ran Build Patch.

How can this be still using InstallShield 2008 ??

I'll try again from scratch to see if something went wrong in my steps.

[Snoopstah]

I started from scratch and could not get past an error when launching my update.exe

"This installation cannot be run by directly launching the MSI package. You must run setup.exe"

I follow the exact same steps in IS 2008 and create update.exe and it runs just fine. Research shows I need to create full latest build without compessing all files.

the patch is now launching and the skin appears, however I consistantly get an error

"Error 2762. Cannot write script record. Transaction not started."

[joshstechnij]

I'm not able to reproduce this behavior with a previous setup built with an older version of InstallShield and the latest (and patch) built with IS 2010.

What release types are the base and upgraded packages (compressed/uncompressed, network/CD-ROM, etc.)? If compressed setups are used, what files are present in the paths pointed to by the latest and previous patch items (there should be uncompressed files in these locations, including ISSetup.dll and setup.ini)?

Note that error 2762 indicates a custom action marked with an in-script execution of deferred (including commit and rollback) is not sequenced between InstallInitialize and InstallFinalize in the execute sequence.

[Snoopstah]

The reason I am totally baffled by this error is that my project is an InstallScript MSI but I have no custom actions. I drive the entire installer via InstallScript. There is not a single action in the CustomActions list that is not a default IS standard action.

The base and upgrade packages are compressed CDROM releases. I had to create my upgrade package as an uncompressed CDROM to get past the
"MSI package" error (although I have never had to do this in prior Installshield releases???)

The compressed setup paths are pointed to in Latest1 and Previous1, pointing to the msi file. IS then prompts me to extract the files to which I say yes and then Latest1 and Previous1 folders are created. These folders do NOT contain issetup.dll nor setup.ini. How do I make these files be extracted from the previous build?

If I point the latest1 and previous1 paths to the compressed SETUP.exe instead of the msi, I am prompted to uncompress the setup. I choose yes and the actual installer is launched.

However during the "preparing to install", an error is generated "Error Number 0x8004072. Description: Failed to load DLL: TerminalServicesCheck. Setup will now terminate". This file is included as a support file in all my builds, however it can't seem to handle support files in the uncompress of my setup.

I'm quite confused as to what path I should be taking.

[joshstechnij]

If the MSI file was selected in the Patch Design view for the latest or previous setups, when the setup is uncompressed, ISSetup.dll and setup.ini will not be copied to the uncompressed location (we don't necessarily know the name of the setup.exe if it was not explicitly selected). When a setup.exe is selected (which should be done for InstallScript MSI projects), then we are able to locate ISSetup.dll and setup.ini and copy them to the uncompressed location. If these files are missing, the wrong ISSetup.dll will be streamed into the update.exe, and the update.exe's setup.ini may not be marked as being a script driven setup (which is needed for InstallScript MSI projects, otherwise an error "This installation cannot be run by directly launching the MSI package. You must run setup.exe" will be displayed).

Please try the following:
1. Migrate the IS 2008 project to IS 2010.
2. Build the release that will be the latest release.
3. Create a new patch configuration in the Patch Design view.
4. For the latest setup, browse to the location of the setup build in step 2, and select the setup.exe. When prompted to uncompress the setup, select Yes.
5. For the previous setup, select the location of the previous release built in IS 2008, and select the setup.exe. Select Yes if prompted to uncompress this setup also.
6. Confirm that both uncompressed locations for the latest and previous setups contain ISSetup.dll and setup.ini (previous should have ISSetup.dll version 14.x, latest should have 16.x).
7. Build the patch and test.

[Snoopstah]

When i perform this step :

4. For the latest setup, browse to the location of the setup build in step 2, and select the setup.exe. When prompted to uncompress the setup, select Yes.

I get an error when the setup.exe is launched to uncompress.

During the "preparing to install", an error is generated "Error Number 0x8004072. Description: Failed to load DLL: TerminalServicesCheck. Setup will now terminate".

This file is included as a support file in all my builds.

[Snoopstah]

If I remove the TerminalServicesCheck.dll and any call to it from my updated installer, the extraction works.
Or course this is not the solution because this same file exists in my "previous1" build. So I can't extract that setup.exe.

So what can be wrong with the one file that is causing the error?

[joshstechnij]

This error occurs when calling a function in a DLL after a call to load the DLL with UseDLL fails to load the it. UseDLL calls LoadLibrary to load DLLs. If LoadLibrary fails to load the DLL, any calls to functions in the DLL in script after UseDLL will fail. Note that LoadLibrary typically fails because it could not locate or load dependencies that the original DLL requires to load successfully.

What error is reported by Err.LastDllError after calling UseDLL?

Note that you also may try moving the code that loads and calls this DLL to an event that is not called in an administrative installation (such as OnFirstUIBefore and/or OnMaintUIBefore) if it is not needed to perform an admin install.

[Snoopstah]

The DLL function is called in OnBegin to determine if Terminal Services is present (not sure where else I could move this as it is something I want to determine at the beginning of EVERY install type).

The dll is in my SUPPORTDIR for the Previous1 and Latest1. The "error" is happening during creation of the patch build in the "extraction" of previous1 and latest1. The DLL has NOT been placed in a temp directory in the Latest1\Prvious1 extraction as it would be if we were running the actual install. I think this is what is causing the problem.

I can't change the script or files in the Previous1 as it has been released to our clients.

Our installs require users to be logged in as administrators to install the product so I'm unsure why this is causing an issue.

[joshstechnij]

The reason the DLL is not present in the temp folder in an admin install is because support files are not extracted for admin installations (since an admin install is only decompressing/copying the installation files to a specified location, support files should not be needed). It is possible to have support files extracted for admin installs by adding the ISSetupFilesExtract and ISSetupFilesCleanup custom actions to the admin UI sequence and admin execute sequence in the Sequences view.

Note that these setups need to be decompressed as that is a Windows Installer requirement for creating a patch. An admin installation is run to decompress the files contained in the setup for this purpose without requiring another uncompressed build of the setup be created..

[Snoopstah]

So basically you are telling me I'm in an un-fixable place. I cant' rebuild the "previous1" as it's already been released.

[joshstechnij]

You could build an uncompressed version of the previous setup if you aren't using dynamic file links; the rebuilt setup does not need to be deployed. Or, you can run an admin install of the previous MSI package (msiexec.exe /a "C:\PathToMsi\MsiPackage.msi") and manually copy setup.ini and ISSetup.dll into the target path where the admin install was decompressed to.

In either case, the latest setup should be changed to either not run any system checks dependent on support files in admin installations, or ISSetupFilesExtract and ISSetupFilesCleanup (though ISSetupFilesCleanup is not necessary for InstallScript MSI projects as the InstallScript engine cleans up the support folder) should be added to the admin UI and execute sequences. Otherwise, this issue will continue to occur for any future patches that are created for the installation.

[Snoopstah]

Fantastic. Thanks. I have now progressed past the issue with the DLL.

My next problem (never ending aren't I) is the upgrade is not behaving correctly on Vista OS.

Both my projects (previous1 and latest1) have digital signatures in the install applied via a pfx file with password. I have checked "sign the patch package" and "sign update.exe" checkboxes and made sure the same pfx file and password applied to the patch build.

Upon install, the patch has successfully updated my file in: C:\Program Files\CompanyName\ProductName
So it appears to have run with elevated privileges to write to the program files folder.

The following registry key has also been updated indicating that elevated privileges were invoked to write to HKLM.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{MyProductID}
Value: DisplayVersion
Data: Correctly updated

However, the following registry entries are not being updated.

HKLM\Software\MyCompanyName\MyProductName\
Value: CurrentVersion
Data: not correctly updated, still shows "old" version.
The installscript call to RegDBSetKeyValueEx to update my product's CurrentVersion has been called but returns -1. This function works in every other install so i know the code itself is accurate.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\InstallShield_{MyProdID}
Value: DisplayVesrion
Data: not correctly updated, still shows "old" version.
This has resulted in TWO entries in add/remove programs, one showing the old pre-patch version, and one showing the new updated version.

If the user runs the patch with "run as administrator" it all works perfectly, which leads me to believe it is something to do with elevated privileges.

Any advice on this is greatly appreciated.

[joshstechnij]

When you run this patch on Vista by double-clicking the update.exe, do you get a UAC prompt when Windows launches the file? If not, the update.exe is probably manifested as invoker. Windows Installer can deal with this situation when you sign the patch and base MSI because it then trusts the patch and runs with elevated privileges (it can do this because the MSI service is always running under the SYSTEM account; it uses impersonation to run with lower privileges in per-user installations). However, the InstallScript engine doesn't have any such mechanism. As a result, it runs with whatever privileges the update.exe was launched with. On Vista with an as invoker manifest, this is typically user privileges.

If you are building this patch in IS 2009 or newer, the patch build will attempt to use the manifest stored in the setup.exe that is in the same location as the latest release (if there isn't a setup.exe there, it uses the as invoker manifest). You should be able to copy the setup.exe from your latest setup into the location the latest setup was decompressed to.