Bugs Bulletin
[ MSI Engine | MSMs |
InstallShield 12 and newer |
InstallShield 11.5 |
DevStudio 9.0 |
IS Dev
8.0 | IS Dev
7.0 | IPWI 2.0 | ISWI 1.x | IS Pro 7.x | IS
Pro 6.x | IS Pro 5.x ]
Last version: 2.03
Released: March 6, 2001
Downloads:
Registered owners of IPWI 2.0 can download the 2.03 maintenance release from http://support.installshield.com/download/ipwi203.asp.
Registered owners of IPWI 2.0 German Edition can download the 2.03 maintenance release at http://support.installshield.com/download/ipwi203_ge.asp
An updated Setup.exe to support MSI 2.0 is available from knowledge base article Q105501.
Release Notes: A list of fixed bugs and open issues can be found at http://support.installshield.com/download/ipwirelnotes.asp
Warning: After updating IPWI be sure to re-install your language packs before
you open any project. Else all your string tables may be converted to English by the
project update tool.
Known Problems in IPWI 2.03
Error 1406 on Windows 9x
- Description:
- While running your setup on Windows 95/98/Me you may get the following error message:
"Error 1406: could not write value folders to key
Software\Microsoft\Windows\CurrentVersion\Installer\InProgress. Verify you have sufficient
access to that key, or contact your support personnel." The same setup works without
problems on Windows NT/2000.
- Cause:
- In the Windows Installer, only directories in all upper-case are public and hence shared
between the UI sequence and the execute sequence. In 2.03, upper-case entries are normally
used to prevent surprising errors when a directory value is not maintained between the UI
sequence and the execute sequence. Windows Installer stores all directory table entries
that are in upper case in the above mentioned registry location. That is not a problem on
NT systems, but may exceed the registry key size limit on Windows 9x if you have many
directory table entries.
- Workarounds:
- Post process the MSI file to change the directory table entries to lower case so they
won't get stored in registry. Or revert to IPWI 2.01 which did not store all the directory
entries in upper case.
- Status:
- This is a limitation in the operating system.
- Created: 2001-11-08
Setup with MDAC Merge Module Randomly Launches other Setup Program
- Description:
- While running the setup, another install program may be launched. This happens if
another installer has left behind its setup.exe in the TEMP directory.
- Cause:
- The mdac.msm extracts mdac_typ.exe to the temp directory, and launches it with the
command line parameters /q /c:"setup /qn1". Note that it's using
"setup" not "setup.exe". A file called setup without .exe doesn't
exist, and this seems to trigger a search algorithm in mdac_typ.exe, and it launches the
first setup.exe it can find that resides in the same directory as mdac_typ.exe.
- Workarounds:
- Include and run mdac_typ.exe from a custom action with the proper command line
parameters.
- Status:
- This problem is reproducible with the MDAC 2.5 SP1 and MDAC 2.6 merge modules in IPWI
2.03 and ISD 7.00.
- Created: 2001-08-30
MDAC 2.5 and 2.6 Merge Modules Don't Merge Properly
- Description:
- The MDAC 2.5 and 2.6 merge modules sometimes don't merge properly. The custom actions
and other properties don't get merged and when you validate the msi package it has about
48-60 ICE03-ICE27 and other errors. This probblem did not exist in ISWI 2.01.
- Workarounds:
- Include and run mdac_typ.exe from a custom action.
- Status:
- InstallShield confirmed that this is a problem in the MDAC merge module. It will not be
fixed in IPWI 2.x.
- Created: 2001-08-30
ICE03 Error "String overflow in registry table" when Validating Merge
Modules that Contain COM-Components
- Description:
- If you create a merge module that contains a com-component (ActiveX control or local
server) and then validate it you get "ICE03 Warning String overflow (greater than
length permitted in column); Table: Registry, Column: Registry .....".
- Cause:
- When you switch the setting for "Registration" under "Advanced
views/Components" from "Use advanced settings" which is the default to
"Extract at build" the following happens: The ModuleID (GUID) which is placed in
the registry table is appended with "_O" and the ModuleID once again. The result
is a string that exceeds the column width specified in the column definition.
- Workarounds:
- None.
- Status:
- Installshield confirmed that this is a bug in IPWI2.03.
- Created: 2001-08-30
Error 1911 "Could not Register Type Library"
- Description:
- Error 1911 "Could not register type library for file [2]. Contact your support
personnel." during installation of one or more components on the target system. All
dependencies are installed correctly, and the components that raise the 1911 error
register properly when you use regsvr32 (dll/ocx) or the /regserver command-line switch
(EXE). The components are set up correctly in Installshield.
The components that cause the error message are configured to use "extract at
build" for their COM registration information. The problem only seems to occur after
binary compatibility has been broken (as it often is, during development), and when you
are using the same machine for compilation of the application object files and creation of
the install set..
- Cause:
- The "extract at build" functionality appears to be using the registry
information for the wrong (old) versions, and is using the wrong interface identifier
information/registry information. This is what generates the 1911 error.
Note: Error 1911 can also be caused by missing dependencies, locale-specific components,
corrupted object files, and several other causes. It is a bit of a catch-all message for
COM registration problems.
- Workarounds:
- To avoid the problem unregister the components before you build the new version that is
not binary compatible. If you already have outdated information in the registry of your
development machine, run RegClean from Microsoft or a similar tool to remove the incorrect
registry entries. Alternatively, create the install set from a machine with a fresh OS
installation. RegClean can be downloaded from these locations: ftp://ftp.uakom.sk/pub/mirrors/sac/utilmisc/regcln41.exe
or ftp://ftp.cs.tu-berlin.de/pub/msdos/mirrors/stuba/pc/utilmisc/regcln41.exe
- Status:
- This problem das been reported for ISWI 1.x, IPWI 2.x and ISD 7.00.
- Created: 2001-08-30
Setup with InstallScript Custom Action Instantly Terminates with SetupCompleteError
Dialog
- Description:
- A setup that includes custom actions written in InstallScript may fail and instantly
show the SetupCompleteError dialog. This happens if the setup is an update and the
previously installed version did not include InstallScript actions.
- Cause:
- In order to run InstallScript code, the InstallScript engine must be installed on the
target computer. This is done with action EngineStartUp which is automatically added to
your setup by IPWI if you are using InstallScript custom actions. However the
EngineStartUp action has a condition of Not Installed and there doesn't run in an update
install.
- Workarounds:
- Post-process your MSI file with Orca to remove the condition on the EngineStartupAction.
- Status:
- This problem is reproducible with IPWI2.03. Documented in InstallShield knowledge base
article Q105420.
FIXED in ISD 7.00.
- Created: 2001-08-30
Cannot Import Projects from IPSE 6.30
- Description:
- IPWI can import project files created with InstallShield Professional - Standard Edition
6.x. However this only work for projects created with IPSE versions before 6.30. Instead
you get the following error messages: "Warning -62: Could not find section [Language]
in file C:\My Installations\MyProject.ipr" and "Fatal error -112: Could not find
section [Data] in file C:\My Installations\MyProject.ipr"
- Cause:
- In IPSE 6.30 the project file format has been changed.
- Workarounds:
- None.
- Status:
- InstallShield confirmed that this is a bug in IPWI 2.03.
- Created: 2001-08-08
Component Wizard Doesn't Use Path Variables
- Description:
- If you use the Component Wizard to add a file, even if a path variable exists for that
location, you get the full path assigned to it, not the path variable.
- Workarounds:
- Change the path entry manually.
- Status:
- InstallShield confirmed that this is a problem in ISWI 1.5. It is not listed in the IPWI
2.0 or 2.01 release notes as fixed or open issue.
FIXED in InstallShield Developer 7.0
- Created: 2000-06-05 Last update: 2001-08-08
InstallShield work order: 1-14NAY
Path Variables Not Used if Files are Added by Drag and Drop
- Description:
- If you use the Add dialog to insert a file into a component, ISWI will use existing path
variables or suggest a new variable for the source path of the file (except if path
variables are turned off). However if you add a file by dragging it from Explorer and
dropping it on the IDE, ISWI always uses the full absolute path to the source file.
- Workarounds:
- Use the Add dialog, or use the Convert Paths wizard to replace absolute paths with path
variables afterwards.
- Status:
- This problem has been reported for ISWI 1.50 and 1.52. It is not listed in the IPWI 2.0
or 2.01 release notes as fixed or open issue.
FIXED in InstallShield Developer 7.0
- Created: 2000-09-17 Last update: 2001-08-08
Ctrl+F7 Key Doesn't Start Compiler
- Description:
- Pressing Ctrl+F/ should start the InstallScript compiler, hower it does nothing.
- Workarounds:
- Click on the compile button on the toolbar or use the menu to invoke the compiler.
- Status:
- InstallShield has confirmed that this is a bug in IPWI 2.03.
FIXED in InstallShield Developer 7.0
- Created: 2001-05-05 Last update: 2001-08-08
Wrong Entries for AppPath Registry Key in Merge Modules
- Description:
- When building a merge module the value in the the Application Paths area (under Advanced
Settings) for a component do not have the module GUID appended to it, i.e. [INSTALLDIR] is
not replaced with [INSTALLDIR.728A5CA8-2EC6-11D5-A5E1-0004ACDD2460]. When the merge module
is used the AppPaths registry entry points the install location of the main install not
the location of the merge module, which may be different.
- Workarounds:
- Append the merge module GUID manually to INSTALLDIR either directly in the IDE or
through Orca.
- Status:
- InstallShield has confirmed that this is a bug in IPWI 2.03.
FIXED in InstallShield Developer 7.0
- Created: 2001-04-26 Last update: 2001-08-08
InstallShield Logo Misplaced After Resizing Dialogs
- Description:
- Each dialog has a control about 4/5 way down which is a single line with the text
"InstallShield" on the left hand side. This control cannot be moved or altered
in any way. If you resize a dialog (as you need to do frequently with multi-languages),
this control is moved in the dialog you resize to keep its position from the bottom of the
dialog, but not in any of the others (which are also automatically resized). This means
that as soon as you alter one dialog, the others have this control completely misplaced -
it may be across the middle of the dialog, or out of sight (if you made the dialog
smaller). Each dialog that you try to fix makes the others worse, with the extra catch
that the "InstallShield" text gradually gets out of synch with itself and
becomes illegible.
- Workarounds:
- None.
- Status:
- InstallShield has confirmed that this is a bug in IPWI 2.03.
FIXED in InstallShield Developer 7.0
- Created: 2001-06-27 Last update: 2001-08-08
Some Data Sources are Not Created
- Description:
- Some of the DSNs you specified in your project may not be created on the target machine.
This happens if you create a DSN, then rename the DSN and the associated component, and
finally create another DSN.
- Cause:
- Both DSNs get the same internal name, so only one of them makes it into the MSI file
(the name is the primary key in the ODBCDataSource table).
- Workarounds:
- Create all your DSNs before you start renaming. This will make sure they get unique
names with incremental numbers.
- Status:
- InstallShield has confirmed that this is a bug in IPWI 2.03.
FIXED in InstallShield Developer 7.0
- Created: 2001-04-26 Last update: 2001-08-08
Dialog Disappears in IDE
- Description:
- If you go to the dialogs view and select a dialog to edit the dialog layout, the dialog
may be "gone". That is, it is still listed in the tree view, but if you click
"English" to edit the dialog layout, the right hand pane is empty. This happens
after you renamed entries in the string table.
- Cause:
- If you rename the string table Identifier that defined the path to the bitmap file for a
bitmap control, the whole dialog disappers. To reproduce go to the string table and rename
the Identifier IDS__IsLicenseDlg_9 to something else. Go to the dialog view and you won't
see the LicenseAgreement dialog anymore (if this dialog is currently displayed, go to
another dialog and return, to refresh the dialog editor).
- Workarounds:
- Rename the string table identifier back to its original name. This will bring the dialog
back. (Again you may need to select another dialog and return, to refresh the editor.)
- Status:
- InstallShield has confirmed that this is a bug in IPWI 2.03. It is also reproducible in
IPWI 2.01.
FIXED in InstallShield Developer 7.0
- Created: 2001-04-20 Last update: 2001-08-08
Runtime Error 35601 "Element not found" and Disabled IDE Toolbar Buttons and
Menus When Editing InstallScript
- Description:
- You may receive a runtime error while editing InstallScript code for a custom action.
Subsequently all toolbar buttons and menus in the IDE are disabled, so you are unable to
save your changes. No prompt to save is shown when you exit the IDE.
- Cause:
- This happens if you change the case of a letter in a function name. Sample: Create a
function MyFunction(hMSI), then select the 'y' character in MyFunction (using shift +
right arrow) and replace it with an uppercase 'Y'. A message box with title
"ISUISeqAct" and the following text is displayed:
Run=time error '35601':
Element not found
> ISUISeqAct.VuActionsL.OnCurrFunctionNameChanged
> ISUISeqAct.PropScriptEditor.ScriptEditor1_FunctionNameChanged
- Workarounds:
- None.
- Status:
- InstallShield has confirmed that this is a bug in IPWI 2.03.
FIXED in InstallShield Developer 7.0
- Created: 2001-03-28 Last update: 2001-08-08
Error 2351 with Dynamic Links and Patch Optimization
- Description:
- During file transfer you receive an error message like this: "File key
'F1234_Somefile.exe' not found in cabinet 'Data.cab'. The installation cannot
continue." This happens if you are using dynamic file links in components and have
specified a Previous Windows Installer Package in the Patch Optimization screen, and you
specified "Compress all files" for the release configuration.
- Cause:
- For dynamically linked files, IPWI assigns key names randomly by default, which prevents
the Patch wizard from creating binary patches. With Patch optimization turned on, the
release wizard applies the existing keys to files of the same name in the new release.
Unfortunately it does not sync the file names it packages into the CAB file with the
assigend file keys. Therefore the entries in the MSI file and the file names in the CAB
file no longer match.
- Workarounds:
- You have several options:
- don't use patch optimization
- leave all files uncompressed
- don't use dynamic file links
- Status:
- This problem is reproducible in IPWI 2.01.
FIXED in InstallShield Developer 7.0
- Created: 2001-02-22 Last update: 2001-08-08
InstallScript Debugger Not Working
- Description:
- When you try to debug custom actions written in InstallScript the debugger doesn't stop
at the breakpoints.
- Cause:
- The InstallScript Debugger executable ISDbg.exe is not properly registered.
- Workarounds:
- Register the debugger by running the following command (while the IDE is closed):
<CommonFilesFolder>\InstallShield\IScript\ISDbg.exe /regserver
(replace <CommonFilesFolder> with the actual path on your machine). You will not get
any messages that confirms the registration, but the debugger should now be working.
- Status:
- InstallShield has confirmed that this is an issue in IPWI 2.02.
FIXED in InstallShield Developer 7.0
- Created: 2001-02-22 Last update: 2001-08-08
InstallShield work order: 1-49QVM
Patch Wizard Causes GPF
- Description:
- In some cases, the patch wizard in ISWI will abort with a General Protection Fault
during the process where the two installs are examined for differences. This happens if
you have a long text in the Comment property of the Summary Information Stream.
- Cause:
- Patch wizard addes about 80 characters to the Comment property in the summary
information stream. This can cause the property to exceed the 255 character limit, which
is causing an access violation.
- Workarounds:
- Shorten your text in the Comments property.
- Status:
- Microsoft has confirmed that this is a problem in Windows Installer 1.1 and should be
addressed in 1.2. If it is not, InstallShield will attempt to provide a workaround. It is
not listed in the IPWI 2.0 or 2.01 release notes as fixed or open issue.
FIXED in InstallShield Developer 7.0
- Created: 2000-06-08 Last update: 2001-08-08
InstallScript Compiler Errors Not Reported in Total Error Count
- Description:
- Building your setup: If the InstallScript compiler encounters an error or waring, it is
displayed immediately in the output window, but scrolls out of sight quickly while the
following build messages are issued. At the end of the build a total error and warning
count is displayed, but the InstallScript errors are not added to the count. So you may
end up with 0 errors 0 warnings even if there are syntax errors in your InstallScript.
- Workarounds:
- Scroll up in the output window to see the results from the InstallScript compiler.
- Status:
- InstallShield confirmed that this is a known problem in ISWI 1.1 and 1.5. It is not
listed in the IPWI 2.0 or 2.01 release notes as fixed or open issue.
FIXED in InstallShield Developer 7.0
- Created: 2000-03-25 Last update: 2001-08-08
StreamFileFromBinary Doesn't Release Handles
- Description:
- The StreamFileFromBinary function is used to extract a file that is stored in the binary
table to the support directory, so that it can be used in a custom action. Calling this
function twice results in error 1500 "Another installation is in progress".
StreamFileFromBinary is an InstallScript custom action that can be found in <ISWI
Program directory>\Samples\ScriptSamples\ScriptSamples\Setup.rul
- Cause:
- In the StreamFileFromBinary function, the binary record handle, database handle, and
binary view handle don't get released.
- Workarounds:
- At the end of the StreamFileFromBinary script function are the following lines:
//Close all handles
CloseHandle(hFile);
CloseHandle(hBinaryRecord);
CloseHandle(hDatabase);
MsiViewClose(hBinaryView);
Change them to:
//Close all handles
CloseHandle(hFile);
MsiCloseHandle(hBinaryRecord); // use MsiCloseHandle
MsiCloseHandle(hDatabase); // use MsiCloseHandle
MsiViewClose(hBinaryView); // releases only the
result set for the view
MsiCloseHandle(hBinaryView); // releases the view itself
- Status:
- InstallShield confirmed that this is a known problem in ISWI 1.1 and 1.5. It is not
listed in the IPWI 2.0 or 2.01 release notes as fixed or open issue.
- Created: 2000-05-16 Last update: 2000-10-21
Last version: 1.52
Released: August 1, 2000
Download: Registered owners of ISWI 1.50 can download the 1.52
maintenance release from http://support.installshield.com/download/iswi.asp
Notes: A list of fixed bugs and open issues can be found at http://support.installshield.com/kb/view.asp?pcode=ALL&articleid=Q104517
Known Problems in ISWI 1.5
VXDs Don't Get Updated if Media was Built on Windows NT
- Description:
- If you build your setup on Windows NT, the version information from .VXD and .386 device
drivers will not be extracted. As a result, these files won't get updated on a Windows 9x
target system, because "any version" in the existing file is considered to be
newer than "no version" in the setup you are installing.
- Cause:
- The version WinAPI implementation on Windows NT cannot extract version info from .VXD
and .386 files. There is a workaround as documented in Microsoft's knowledge base article
Q201685, but obviously InstallShield isn't using it.
- Workarounds:
- Build on Windows 9x or populate the version fields in the file table with Orca after you
have built your setup.
- Status:
- FIXED in IPWI 2.03
This problem also exists in the InstallShield Professional product line, with issue number
1-17XGX.
- Created: 2000-10-04 Last update: 2001-03-08
InstallShield issue number: 1-47K0Q
Source Media Required for Uninstall
- Description:
- If you have an InstallScript custom action, you are prompted for the source media (CD
etc.) at uninstall time. Apparently this occurs if the custom action occurs before
InstallFinalize.
- Workarounds:
- Set your InstallScript custom action to "deferred execution" rather than
"immediate execution" or place it after the InstallFinalize action.
- Status:
- InstallShield confirmed that this is a problem in ISWI 1.52.
FIXED in IPWI 2.01 (according to user report - it is not listed in the IPWI 2.0 or 2.01
release notes as fixed or open issue)
- Created: 2000-10-13 Last update: 2000-10-24
ISWI Validation Wizard errors -98 and -146
- Description:
- If you change the size or position of any control in a dialog, you'll get a ISWI
Validation Wizard error "-98 , Field Type of Control MenuText.: Null value for
non-nullable field." for each control you've changed and one "-146 , Field
Control First of Dialog CustomSetupTips.: The first control in the tab order of dialog
CustomSetupTips points to nonexistent control Next as the next element" for each
dialog where a control was changed.
Only ISWI validation reports these errors. Msieval2 doesn't and the setup seems to work
fine.
- Workarounds:
- Make a copy of the dialog you want to change, make the changes you want and copy the
desired controls and close the dialog without saving. Now go to the original dialog,
delete the same controls you copied from the other one and paste them. Now you shouldn't
get these validation errors. You should also go to the string table and delete the old
entries, so as not to get duplicate entries, since ISWI created new entries for each
control pasted.
- Status:
- InstallShield confirmed that this is a problem in ISWI 1.5 and 1.52.
FIXED in IPWI 2.0
- Created: 2000-08-17 Last update: 2000-10-21
VXDs Don't Get Updated if Media was Built on Windows NT
- Description:
- If you build your setup on Windows NT, the version information from .VXD and .386 device
drivers will not be extracted. As a result, these files won't get updated on a Windows 9x
target system, because "any version" in the existing file is considered to be
newer than "no version" in the setup you are installing.
- Cause:
- The version WinAPI implementation on Windows NT cannot extract version info from .VXD
and .386 files. There is a workaround as documented in Microsoft's knowledge base article
Q201685, but obviously InstallShield isn't using it.
- Workarounds:
- Populate the version fields in the file table with Orca after you have built your setup.
- Status:
- This problem also exists in the InstallShield Professional product line, with issue
number 1-17XGX.
- Created: 2000-10-04
StreamFileFromBinary Doesn't Release Handles
- Description:
- The StreamFileFromBinary function is used to extract a file that is stored in the binary
table to the support directory, so that it can be used in a custom action. Calling this
function twice results in error 1500 "Another installation is in progress".
StreamFileFromBinary is an InstallScript custom action that can be found in <ISWI
Program directory>\Samples\ScriptSamples\ScriptSamples\Setup.rul
- Cause:
- In the StreamFileFromBinary function, the binary record handle, database handle, and
binary view handle don't get released.
- Workarounds:
- At the end of the StreamFileFromBinary script function are the following lines:
//Close all handles
CloseHandle(hFile);
CloseHandle(hBinaryRecord);
CloseHandle(hDatabase);
MsiViewClose(hBinaryView);
Change them to:
//Close all handles
CloseHandle(hFile);
MsiCloseHandle(hBinaryRecord); // use MsiCloseHandle
MsiCloseHandle(hDatabase); // use MsiCloseHandle
MsiViewClose(hBinaryView); // releases only the
result set for the view
MsiCloseHandle(hBinaryView); // releases the view itself
- Status:
- InstallShield confirmed that this is a known problem in ISWI 1.1 and 1.5
- Created: 2000-05-16 Last update: 2000-10-04
Path Variables Not Used if Files are Added by Drag and Drop
- Description:
- If you use the Add dialog to insert a file into a component, ISWI will use existing path
variables or suggest a new variable for the source path of the file (except if path
variables are turned off). However if you add a file by dragging it from Explorer and
dropping it on the IDE, ISWI always uses the full absolute path to the source file.
- Workarounds:
- Use the Add dialog, or use the Convert Paths wizard to replace absolute paths with path
variables afterwards.
- Status:
- This problem has been reported for ISWI 1.50 and 1.52.
- Created: 2000-09-17
Patch Wizard Causes GPF
- Description:
- In some cases, the patch wizard in ISWI will abort with a General Protection Fault
during the process where the two installs are examined for differences. This happens if
you have a long text in the Comment property of the Summary Information Stream.
- Cause:
- Patch wizard addes about 80 characters to the Comment property in the summary
information stream. This can cause the property to exceed the 255 character limit, which
is causing an access violation.
- Workarounds:
- Shorten your text in the Comments property.
- Status:
- Microsoft has confirmed that this is a problem in Windows Installer 1.1 and should be
addressed in 1.2. If it is not, InstallShield will attempt to provide a workaround.
- Created: 2000-06-08
Component Wizard Doesn't Use Path Variables
- Description:
- If you use the Component Wizard to add a file, even if a path variable exists for that
location, you get the full path assigned to it, not the path variable.
- Workarounds:
- Change the path entry manually.
- Status:
- InstallShield confirmed that this is a problem in ISWI 1.5
- Created: 2000-06-05 InstallShield work order: 1-14NAY
InstallScript Compiler Errors Not Reported in Total Error Count
- Description:
- Building your setup: If the InstallScript compiler encounters an error or waring, it is
displayed immediately in the output window, but scrolls out of sight quickly while the
following build messages are issued. At the end of the build a total error and warning
count is displayed, but the InstallScript errors are not added to the count. So you may
end up with 0 errors 0 warnings even if there are syntax errors in your InstallScript.
- Workarounds:
- Scroll up in the output window to see the results from the InstallScript compiler.
- Status:
- InstallShield confirmed that this is a known problem in ISWI 1.1 and 1.5
- Created: 2000-03-25 Last update: 2000-05-26
Last version: 1.1
Released: February 1, 2000
Order / Download: The update to InstallShield Professional 2000 Second
Edition can be ordered or downloaded from http://support.installshield.com/download/ispro2000.asp
Notes: A list of fixed bugs and open issues can be found at http://support.installshield.com/kb/view.asp?pcode=ALL&articleid=Q103171
Known Problems in ISWI 1.1
Problems that apply to both ISWI versions, 1.1 and 1.5, are listed under ISWI 1.5
above.
Path Variables Evaluated Wrong
- Description:
- If you create a new path variable by appending an existing path variable to a constant
path, the path is missing some parts. Example:
Create two path variable and define the values as follows:
Path1 : TestDir
Path2 : C:\Test\<Path1>
Now Path2 should evaluate to C:\Test\TestDir (and it did in ISWI 1.03), but in ISWI 1.1 it
is set to only TestDir.
- Workarounds:
- None.
- Status:
- InstallShield confirmed that this is a known problem in ISWI 1.1
FIXED in 1.5
- Created: 2000-03-30 Last update: 2000-05-26
Reboot Fails if Setups Includes InstallScript Custom Actions
- Description:
- After running a setup that uses a custom action written in InstallScript, Windows can no
longer be rebooted. This problem does not only affect the setup itself (reboot dialog does
not reboot) but the whole system (reboot via the Start menu also fails).
This problem has only been reported for Windows NT, not for Windows 9x.
- Cause:
- The iKernel.exe task is still active and prevents the reboot. iKernel.exe is the
InstallScript runtime engine. Terminating this task in the task manager solves the problem
and allows the system to reboot.
- Workarounds:
- Insert a VBScript custom action with deferred execution. In the script call
Session.DoAction("CleanUp"). This will unload iKernel.exe.
You can also do this in a DLL: MsiDoAction (hInstall, "CleanUp");
If you need to start the InstallScript engine again, you can re-start it with
Session.DoAction("StartUp") resp. MsiDoAction (hInstall, "StartUp");
- Status:
- InstallShield confirmed that this is a known problem in ISWI 1.1
FIXED in 1.5
- Created: 2000-03-25 Last update: 2000-06-28
Shortcut to Command Script Doesn't Open DOS Window
- Description:
- After you installed a shortcut to a NT command script, you double click the icon but
nothing seems to happen. In fact, the script is started, but no command prompt window is
opened.
- Cause:
- For shortcuts with the Run property set to "Normal Windows" ISWI inserts the
value 0 in the ShowCmd field of the MSI database. The correct value is 1.
- Workarounds:
- Change the ShowCmd field entries from 0 to 1 after you built the MSI file. You can use
the following command line program for this purpose.
FixShowCmd.zip From newsgroup installshield.iswi.general
File size: 9.355 bytes Last update: 2000-04-06.
- Status:
- InstallShield confirmed that this is a known problem in ISWI 1.1
FIXED in 1.5
- Created: 2000-04-06 Last update: 2000-05-22
ICE03 Error Validating Merge Modules
- Description:
- If you create a merge module and then validate it, you'll receive "Missing
specifications in _Validation Table" error messages.
- Cause:
- The specifications are missing because there were no merge module validation specs at
the time ISWI 1.1 was released.
- Workarounds:
- None.
- Status:
- InstallShield confirmed that this is a known problem in ISWI 1.1
FIXED in 1.5
- Created: 2000-04-01 Last update: 2000-05-22
InstallScript Custom Actions Don't Work in Silent Mode
- Description:
- InstallScript custom actions work correctly if you do a normal install, but they are not
executed if you do a silent installation. They start working after you any setup that uses
InstallScript CAs in normal mode
- Cause:
- In silent mode the InstalShield script interpreter doesn't get installed.
- Workarounds:
- None.
- Status:
- InstallShield confirmed that this is a known problem in ISWI 1.1
FIXED in 1.5
- Created: 2000-04-01 Last update: 2000-05-22
Setup Design Tree View Not Working on French Windows
- Description:
- On systems with French locale settings, the feature tree in Setup Design view of the IDE
doesn't show the feature nodes. This affects the summary and the feature views, however
the component view is working properly.
- Cause:
- In Microsoft newsgroups there are reports about a bug in the tree view control: a key
for the tree may be converted to a number if it is identical to the currency symbol. You
can reproduce the problem by setting your currency symbol to F even on an English version
of Windows.
- Workarounds:
- Follow these steps to change the currency symbol:
1. Close the ISWI IDE.
2. Open Control Panel and launch the Regional Settings icon.
3. Go to the Currency tab.
4. Change the currency symbol from F to FF or Fr for instance.
5. Launch ISW and open your project.
The setup design tree view should now be operational.
- Status:
- This problem has been reported in the newsgroups.
FIXED in 1.5
- Created: 2000-05-19 Last update: 2000-05-22
Last version: 1.03 (This version has been superceded by 1.1 which is
available free of charge for registered users of ISWI 1.0x)
Released: November 15, 1999
Download: http://support.installshield.com/download/iswi.asp
Notes: A list of fixed bugs and open issues can be found at http://support.installshield.com/kb/view.asp?pcode=ALL&articleid=Q103171
Copyright © by InstallSite Stefan
Krueger. All rights reserved. Legal
information.
Impressum/Imprint
Datenschutzerklärung/Privacy Policy
By using this site you agree to the license
agreement. Webmaster contact