Upgrading Projects from InstallShield 2011 or Earlier

InstallShield 2018

The following information describes possible upgrade issues that may occur when you upgrade projects that were created with InstallShield 2011 and earlier to InstallShield 2018. It also alerts you to possible changes in behavior that you may notice between new InstallShield 2018 projects and projects that are upgraded from InstallShield 2011 or earlier to InstallShield 2018.

General Information about Upgrading Projects that Were Created in Earlier Versions of InstallShield

If you use InstallShield 2018 to open a project that was created with an earlier version, InstallShield 2018 displays a message box that asks you if you want to convert the project to the new version. If you reply that you do want to convert it, InstallShield creates a backup copy of the project with a file extension such as .771 before converting it. Delete the .771 part from the original project’s file name if you want to reopen the project in the earlier version of InstallShield. Note that you cannot open InstallShield 2018 projects in earlier versions of InstallShield.

You can upgrade projects that were created with the following versions of InstallShield to InstallShield 2018: InstallShield 2011 and earlier, InstallShield 12 and earlier, InstallShield DevStudio, InstallShield Professional 7 and earlier, and InstallShield Developer 8 and earlier. Note that projects that were created with InstallShield MultiPlatform or InstallShield Universal cannot be upgraded to InstallShield 2018.

Changes that Affect All Projects (New and Upgraded Projects)

This section describes changes that affect both new projects and projects that are upgraded from earlier versions of InstallShield.

Changes in Behavior for Some MSI APIs That Are Called in InstallScript Custom Actions

A change was made to how the InstallScript engine calls Windows Installer API such as MsiGetProperty. The engine now calls the Windows Installer APIs directly instead of using wrapper APIs that in turn call the Windows Installer APIs. This change was made to resolve issues with buffer handling and buffer sizes. It applies to all new projects that you create in InstallShield 2018, as well as projects that you have upgraded from earlier versions of InstallShield to InstallShield 2018.

As a result of this change, you can use the MSI install handle that is passed to a custom action function with all Windows Installer APIs that require an install handle. Previously, the handle was managed by the InstallScript engine, and it could not be passed directly to Windows Installer APIs.

Also as a result of this change, any Windows Installer APIs that require a buffer size to be specified now fail if the buffer size is not correctly specified. Note that 0 is not a valid size; thus, ensure that your code does not pass a zero value for the size of the buffer.

If you have existing InstallScript custom actions that call Windows Installer APIs, ensure that a large enough buffer size is specified; if it is not, unexpected results could occur.

The following sample code demonstrates how to retrieve the value of a Windows Installer property value string in InstallScript and increase the size of the buffer if necessary.

prototype STRING MyGetProperty (HWND, STRING);

//////////////////////////////////////////////////////////////////////////

//   MyGetProperty

//

//   Return an MSI property string value

//   Input Parameters:

//        hMSIHandle:      Handle to the currently running MSI database

//        szPropertyName:  Name of property to retrieve

//    Output:

//        String containing the property value

//////////////////////////////////////////////////////////////////////////

 

function STRING MyGetProperty (hMSIHandle, szPropertyName)

    NUMBER  nvBuf, nResult;

    STRING  szReturn;

begin

 

//Retrieve the size of the property value

    szReturn = "";

 

    nResult = MsiGetProperty (hMSIHandle, szPropertyName, szReturn, nvBuf);

 

    if (ERROR_MORE_DATA = nResult) then

        nvBuf = nvBuf + 1; //increment buffer size for terminating null

 

        //Retrieve the property value

        nResult = MsiGetProperty (hMSIHandle, szPropertyName, szReturn, nvBuf);

 

        if (nResult != ERROR_SUCCESS) then

            szReturn = "";

        endif;

    endif;

    return szReturn;

end;

Note that if the script had used if ( ERROR_SUCCESS == nResult ) then instead of if ( ERROR_MORE_DATA == nResult ) then, unexpected results could occur.

Build Warning -7235 for Basic MSI Projects

By default, software identification tagging is enabled in all Basic MSI projects. This applies to new projects that you create in InstallShield 2018, as well as projects that you have upgraded from earlier versions of InstallShield to InstallShield 2018.

If you build a release in a Basic MSI project without entering data in the required identification tag settings (the Unique ID, Tag Creator, and Tag Creator ID settings in the General Information view), and you leave tagging enabled in the project, build warning -7235 occurs. This build warning explains that the software identification tag could not be created and included in the installation because a specific required setting was left blank. To resolve this warning, enter appropriate value in each specific setting, or select No for the Use Software Identification Tag setting in the General Information view.

COM Extraction Changes

InstallShield supports a new monitoring method for COM extraction. If you are using InstallShield on a Windows Vista or later system or a Windows Server 2008 or later system, this new method is used by default. The method uses a kernel driver to monitor the areas of the registry that are modified during dynamic COM extraction at build time and static COM extraction at design time. It combines the advantages that the earlier methods provided, allowing the DLL to read existing registries entries and preventing changes to the build machine.

If necessary, you can switch between the three different COM extraction methods by setting the value data of the UseAPIRegistryHooks registry value, which is in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\InstallShield\RegSpy (on 32-bit machines) or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\InstallShield\RegSpy (on 64-bit machines). Possible REG_DWORD value data are:

0—Use API hooking to read existing registry entries for the DLL.
1—Use registry redirection to prevent making changes to the registered DLLs on the build machine. If the value is not set, this is the default behavior on Windows XP and Windows Server 2003 systems.
2—Use the new kernel mode monitoring, which combines the advantages of both of the other methods. If the value is not set, this is the default behavior on Windows Vista and later systems and on Windows Server 2008 and later systems.

This functionality applies to the following project types: Basic MSI, DIM, InstallScript MSI, and Merge Module.

String Entries in Merge Module Projects

Each string identifier that is created in a Merge Module project now contains the Merge Module’s module ID GUID. This applies to all new string identifiers that are created in all new Merge Module projects, as well as new string identifiers that are created in existing Merge Module projects that were upgraded from InstallShield 2011 or earlier to InstallShield 2018. Note that if you upgrade a Merge Module project from InstallShield 2011 or earlier to InstallShield 2018, the module ID GUID is not added to the string identifiers of any existing string entries.

The use of the GUID in string identifiers of Merge Module project string entries helps to minimize or eliminate conflicts that would occur if the same string identifier is used in a Merge Module project and also in an installation project that contains that Merge Module, and if different values are assigned to those two string identifiers.

See Also