Jennifer
05-19-2006, 12:12 PM
How does InstallShield normally document changes in their product that will require their users to change their installations as well?
I have had to change a number of my installscript custom actions to use CustomActionData. I had no clue I had to do this until I encountered a problem.
And that's how I usually find out I have to make changes. But shouldn't there be a comprehensive document that says in detail "if you used to do that then you will have to do this now" instead of "you won't be able to do that anymore"
Case in point (from release notes):
The InstallScript MSI architecture has had a number of issues with security (COM/DCOM) and other areas that can cause some installations to fail for various reasons. The architecture has been improved dramatically for InstallShield 12 to resolve these issues and to make InstallScript MSI a more reliable project type. The improvements also help increase the reliability of Basic MSI projects that include InstallScript custom actions.
From the above excerpt, should I have known that I need to start using CustomActionData from now on? And when I did a search on how to use CustomActionData in InstallShield's help libraries it pointed me to the Windows Installer documentation.
Shouldn't there be some sort of comprehensive documentation that lists the changes users will have to make and how to do them in order to upgrade to a version of InstallShield that has made significant architectural changes.
Not that I don't mind performing searches in InstallShield's help library or the Windows Installer SDK help or in InstallShield's KB articles and having to reconcile information on all three. :D
I have had to change a number of my installscript custom actions to use CustomActionData. I had no clue I had to do this until I encountered a problem.
And that's how I usually find out I have to make changes. But shouldn't there be a comprehensive document that says in detail "if you used to do that then you will have to do this now" instead of "you won't be able to do that anymore"
Case in point (from release notes):
The InstallScript MSI architecture has had a number of issues with security (COM/DCOM) and other areas that can cause some installations to fail for various reasons. The architecture has been improved dramatically for InstallShield 12 to resolve these issues and to make InstallScript MSI a more reliable project type. The improvements also help increase the reliability of Basic MSI projects that include InstallScript custom actions.
From the above excerpt, should I have known that I need to start using CustomActionData from now on? And when I did a search on how to use CustomActionData in InstallShield's help libraries it pointed me to the Windows Installer documentation.
Shouldn't there be some sort of comprehensive documentation that lists the changes users will have to make and how to do them in order to upgrade to a version of InstallShield that has made significant architectural changes.
Not that I don't mind performing searches in InstallShield's help library or the Windows Installer SDK help or in InstallShield's KB articles and having to reconcile information on all three. :D