cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Lou_Elston
Pilgrim

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?
Labels (1)
0 Kudos
5 Replies
Highlighted
Not applicable

Re: SUPPORTDIR problem

You can get SUPPORTDIR property through MsiGetProperty function.
0 Kudos
Lou_Elston
Pilgrim

SupportDir

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?
0 Kudos
Highlighted
DebbieL
Pilgrim

Re: SUPPORTDIR problem

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:
0 Kudos
Highlighted
Lou_Elston
Pilgrim

Why these changes (InstallScript VS MSI)?

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?
0 Kudos
Highlighted
DebbieL
Pilgrim

Re: SUPPORTDIR problem

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.
0 Kudos