I have a version of a software installed, when calling the setup the InstallScript MSI project for a newer version, Installshields asks if I wish to update the software. If I click on yes, it runs a while, but I am getting a fatal error 1603 during the update.
I tried to activate the logging when updating, and the last entries in the log are:
I'm not sure the "Unable to delete file" error is related to the root problem, since this is just the MSI engine shutting down and attempting to clean up. Can you attach the log file where this 1603 error occurs?
How does it come that I have this 1603 failure when the older application is installed with french as choosen installation language, but not when selecting german?
I'm not sure why this problem occurs specifically when selecting French as the install language. Unfortunately, the log information present doesn't contain any indications of where the failure is occurring or why.
What is more likely is something is causing the script to abort: [CODE]MSI (c) (DC:1C) [time]: Note 1: 2205 2: 3: ISAlias 4: SELECT * FROM ISAlias InstallShield : Installation aborts, ready to shut down. InstallShield : Invoking __ResetMsiObject...[/CODE]
Have you changed the OnResume event in your script? If so, can you add a MessageBox call to the beginning of the event to see if the OnResume event is actually running?
I have an InstallScript-MSI upgrade installer (InstallShield 2008) that hangs at the following point, but only on Vista?
This occurs AFTER feature selection during the upgrade process. The last feature is properly selected, then the upgrade goes haywire. So I don't think there is any problem with features (the features are the same, no additions, no name changes).
There is NO ISAlias table in the compiled installer's .MSI because there is no "alias" information in the PROJECT's ISAlias table. So I can understand why a table error is getting tossed. The table being looked for is missing. What I DON'T understand is why the installer setup.exe is triggering a lookup of that table in the first place.
The ISAlias table is used in projects that were converted from InstallScript to InstallScript MSI (in Developer 7/8) to allow for component, feature, directory keys to be able to contain invalid characters that are not allowed in MSI table keys. The InstallScript MSI runtime will always query this table to determine if any key aliases exist in the running project.
Querying the table, whether it is present or not, will not typically cause a project to abort. The existing log information in this thread showed projects aborting in unrelated script code. A script abort could be caused by an exception related to attempting to use a COM object that wasn't created or throwing an error, or some other user related script code issue. The location of the error can be isolated by including a default script in the project. If the issue still occurs, the issue is occurring in InstallScript runtime script code; if the issue no longer occurs, the issue is in user script code. If the issue does appear to be in the InstallScript runtime, we need to be able to reproduce the issue to determine what the cause could be.
Thank. Yes, I read the help file and understand the use of the ISAlias table. None exists in my project because it has been a LONG time since we have converted anything from those older versions of InstallShield. As far as I could tell, there were no problems with the names of any features or components.
The problem with my project is NOT that it is aborting. It is that it is hanging on Vista at the point where the query to the ISAlias table is being done. The installer just sits there without returning any sort of response. It does this on Vista.
Of course, that is no guarantee that the problem is there. It could be the NEXT thing (whatever that is), or something going on in some independent thread.
I actually tried importing an empty ISAlias table (using ORCA) in the compiled installer MSI, and I got another error number that told me nothing.
joshstechnij wrote: The ISAlias table is used in projects that were converted from InstallScript to InstallScript MSI (in Developer 7/8) to allow for component, feature, directory keys to be able to contain invalid characters that are not allowed in MSI table keys. The InstallScript MSI runtime will always query this table to determine if any key aliases exist in the running project.
Querying the table, whether it is present or not, will not typically cause a project to abort. The existing log information in this thread showed projects aborting in unrelated script code. A script abort could be caused by an exception related to attempting to use a COM object that wasn't created or throwing an error, or some other user related script code issue. The location of the error can be isolated by including a default script in the project. If the issue still occurs, the issue is occurring in InstallScript runtime script code; if the issue no longer occurs, the issue is in user script code. If the issue does appear to be in the InstallScript runtime, we need to be able to reproduce the issue to determine what the cause could be.
Whether the project is hanging or aborting at this particular point in a log, the troubleshooting steps will be basically the same. The behavior you are seeing needs to be isolated before further action can be taken: - Is this behavior occurring on all Vista machines (including ones with a clean install of Vista) or is it isolated to one or a couple of machines? - Does a sample InstallScript MSI project with one feature, one component, one file, and a default setup.rul run on these machines? - If a sample project works, does including a default setup.rul in your project change the behavior of the setup?
Note that regardless of whether a project was migrated from older versions on InstallShield or not, the InstallScript MSI runtime contains code to check for MSI key aliases in the ISAlias table. If none are present for features, components, setup types, or directories, the internal script code continues with the setup.
The VerGetFileVersion function is mostly a wrapper around the Windows version information APIs. Unless these APIs have an issue on Windows Vista, I'm not certain why any hangs may be occurring while calling this function. Are you able to reproduce this behavior with a sample project on Vista?
It turned out that the issue was NOT the file version function.
This was a complex client-server installation. We were installing the client side, which checks the version of the server application during upgrade by grabbing the server path from the registry (where we put it on initial installation).
When the user updates the Client side, we check that the Admin has updated the server component of the application before proceeding.
The upgrade installer grabs the path using RegLocator and AppSearch tables and saves it to a property. The script grabs the property using MsiGetProperty. BUT, the Buffer for MsiGetProperty was not reset and the path retrieved was getting truncated. Hence the server component could not be found and the version could not be retrieved. We reset the buffer value to something longer and we added a little more checking for return of the version number.
Since the Installscript was running asynchronously, without writing to the Msi Log at that point, we were getting other information than the error source in the verbose log, which was confusing me (it seemed to be hanging at the ISAlias table, but that was not the issue).
I guess the lesson here is to remember to reset the nBuffer property to an appropriate value EVERY TIME you use the MsiGetProperty function, or you may be getting a short buffer from the previous function call.