String Too Long with MsiGetProperty with Installshield Installscript

Question

I use MsiGetProperty to get the value of a string parameter from the installer. And after that I call the managed dll and I pass this value:

nvBufferSize = MAX_STRING; MsiGetProperty (hMSI, "DBHMS", sDbHost, nvBufferSize); 

when I pass the value of sDbHost, this happens when I get it from managed code: srvdata-02NULNULNULNULNULNUL ...... however, in the interface I wrote only "srvdata-02".

With the same code, it was fine with Installshield 2010, now I am updating it to installshield 2012. Do you have any solution with this?

Answer 1

There were some behavior changes in MsiGetProperty some time ago. Try setting nvBufferSize to MAX_SIZE instead of MAX_STRING. Also check the MsiGetProperty return code to make sure it is ERROR_MORE_DATA or if it returns any other code. Finally, check the nvBufferSize value to see how many bytes are needed.

By the way, if you are just trying to arrange a property for managed code, you might want to look into the Deployment Tools Framework (DTF) in Windows Installer XML (WiX). This is a very nice SDK that allows you to write managed code user actions and package them as if they were native Win32 libraries. InstallShield can then easily use this as a custom MSI DLL action.

DTF provides an interop library and a session object that can be used as:

• Managed Deployment Tool User Actions (DTF)
• Reasons DTF is Better

Answer 2

As funny as it may seem, here's a working InstallScript solution:

 nvBufferSize = MAX_STRING; nResult = MsiGetProperty( ISMSI_HANDLE, szPropertyName, svValue, nvBufferSize ); if( nResult = ERROR_MORE_DATA ) then MsiGetProperty( ISMSI_HANDLE, szPropertyName, svValue, nvBufferSize ); endif; 

The first attempt returns the required buffer size. If it is more than max string (1024?), The second call gets everything.

As an alternative, I found that I could assign nvBufferSize a larger value right away with a bat, for example. 4096 and use this with a single call (provided that the data is no longer such). The double challenge, however, is more conclusive.

According to: https://msdn.microsoft.com/en-us/library/aa370134(v=vs.85).aspx the api function is actually designed to return buffering by passing an empty literal ("") instead of a string variable. InstallScript 2013 throws a compilation error if you try to do this ...