This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- SUPPORTDIR problem
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 02, 2011
04:46 PM
SUPPORTDIR problem
Converting 10.5, Basic MSI Project, with InstallScript functions, to IS 2012. Testing on Windows Server 2008 R2. Files in SUPPORTDIR are no longer found. I put in MessageBox's, everytime I run, the value of SUPPORTDIR changes. Any Ideas?
(5) Replies
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 03, 2011
06:45 AM
You can get SUPPORTDIR property through MsiGetProperty function.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 03, 2011
05:53 PM
I know how to use GetProperty. I am asking why that value changes every time I run the installer? The 10.5 version works, the 2012 does not, is there a reason?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 05, 2011
08:22 AM
In InstallShield 12, some major improvements were made to the InstallScript architecture. As a side effect, you'll see the behavior that you described in each version of InstallShield starting with InstallShield 12. For more information, see:
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 09, 2012
07:06 PM
What is the reasoning behind the changes to InstallScript projects? Is this an effort to move projects to the MSI type project? I just started a new contract, and I need to upgrade some installers from 6.3 InstallScript, to 2012 (yes I did say 6.3). It will not be just an upgrade from one IS version to another, there will be some changes to the installer itself. The product files are written in 2008 C++, not .Net), so if I go with a MSI project, the custom actions will be in C++. Is there a reason that I would want to stay with InstallScript?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 10, 2012
09:53 AM
I think I’m a little confused about what you are trying to do. It sounds like you are working with a wide range of projects (InstallShield 10.5 Basic MSI, InstallShield Professional 6.3 InstallScript, and maybe more).
Pure InstallScript projects haven’t changed much since InstallScript events were introduced. The recent addition of Unicode support to InstallScript in InstallShield 2011 may necessitate some minor changes to projects, but nothing architectural. (For example, if you use any user-defined Win32 APIs or other external DLL prototypes in your InstallScript code, and the APIs have versions that support Unicode string input, you’ll want to update the prototypes to use BYVAL/BYREF WSTRING or WPOINTER. For more details, see Upgrading Projects from InstallShield 2010 or Earlier.)
The use of InstallScript in a Windows Installer–based project required the architecture changes that were made in InstallShield 12; these changes may require more significant changes to your projects, as described in the help topics that I listed in my earlier post in this thread.
If you are trying to decide whether to use a Windows Installer–based project vs. an InstallScript project, see Determining Which Installation Project Is Right for You.
If you are trying to decide between InstallScript custom actions and C++ custom actions, the biggest factor in your decision will likely be which language you (and your team/customer) are familiar with. If you are thinking of changing InstallScript custom actions to C++ actions, both types of custom actions will now have the same property access and limitations, so there’s no architectural win with regard to interacting with Windows Installer.
Pure InstallScript projects haven’t changed much since InstallScript events were introduced. The recent addition of Unicode support to InstallScript in InstallShield 2011 may necessitate some minor changes to projects, but nothing architectural. (For example, if you use any user-defined Win32 APIs or other external DLL prototypes in your InstallScript code, and the APIs have versions that support Unicode string input, you’ll want to update the prototypes to use BYVAL/BYREF WSTRING or WPOINTER. For more details, see Upgrading Projects from InstallShield 2010 or Earlier.)
The use of InstallScript in a Windows Installer–based project required the architecture changes that were made in InstallShield 12; these changes may require more significant changes to your projects, as described in the help topics that I listed in my earlier post in this thread.
If you are trying to decide whether to use a Windows Installer–based project vs. an InstallScript project, see Determining Which Installation Project Is Right for You.
If you are trying to decide between InstallScript custom actions and C++ custom actions, the biggest factor in your decision will likely be which language you (and your team/customer) are familiar with. If you are thinking of changing InstallScript custom actions to C++ actions, both types of custom actions will now have the same property access and limitations, so there’s no architectural win with regard to interacting with Windows Installer.