Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Using MsiGetProperty in a BASIC MSI


4 replies to this topic

RayKode

RayKode
  • Full Members
  • 58 posts

Posted 28 September 2005 - 15:31

Good Wednesday moring everyone,

I have a need to retrieve the version number, of the product currently being installed and then to write it into a file.

When I look at the Property table of my MSI via ORCA, I see a property named "ProductVersion" that has the exact value I am looking for.

However, I can't seem to access this property with any success via a custom action running an InstallScript function.

I coded my MsiGetProperty command using the information from the following InstallShield article (http://helpnet.insta...&ctxid=view.asp).

Although the command runs, it dosen't return a value, at all.

Any suggestions as to how I might go about retrieving the Product Version value ?

Thanks in adavnce for all responses.

Ray in Wisconsin.





Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 06 October 2005 - 12:58

Did you pre-set the size parameter in the MsiGetProperty function? You must initialize it to the size of the variable that should receive the proeprty value. If it's not set (0) you will receive only 0 bytes.

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 06 October 2005 - 21:33

Is the Custom Action a commit CA, deferred CA or rollback CA? In such CAs you request very few properties, ProductVersion is not one of them.

RayKode

RayKode
  • Full Members
  • 58 posts

Posted 07 October 2005 - 15:27

Good Friday folks,

Thanks for the reply.

Here's the code I was trying to use.

function MyFunction(hMSI)
// To Do: Declare local variables.
STRING svResult;
NUMBER nvSize;
begin

// To Do: Write script that will be executed when MyFunction is called.
nvSize = 256;
MsiGetProperty (ISMSI_HANDLE, "ProductVersion", svResult, nvSize);
MessageBox (svResult, INFORMATION);

end;

I am trying to write a line into a file on the hard disc of the PC ONLY if the installation was successful.
Part of this line was to have the ProductVersion number in it.

So, I was trying to use the above code as part of a "Commit" custom action.

I found documentation that indicated a "Deferred" custom action had a limited number of properties available to it.
But nothing that said the same was true for a "Commit" custom action.

Dosen't mean no documentation exists.
Only that I caouldn't find any.

I CAN sucessfully use the above code in a custom action (other than a commit or deferred) within the execute sequence.

Now, I don't want to hear any laugher(I'm kinda new to IS) but, here's what I did as a work around.

I get the value of the ProductVersion property, via a custom action within the UI sequence, then write the value to the registry.

Then, during my "Commit" custom action within the execute sequence, I retrieve the value written to the registry, create my file and finally, delete the registry entry.

I also created another custom action to delete the registry key in the event the "Commit" custom action doesn't fire. (Not a sucessful installation.)


Not elegant but, it DOES work.

Any other ideas would be appreciated as some day, another person might take over these duties and I don't want to embarass myself by leaving behind this kind of code.

Thanks again for both of your responses.



Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 11 October 2005 - 09:17

A commit action is a special case of a deferred action.
The MSI way to do this:
1. Deferred action to make a backup copy of the file you want to write to.
2. Deferred action that writes to the file.
3. Rollback action that deletes the modified file and copies back the original file.
4. Commit action that deletes the backup file.

If writing to the registry instead of a file would be an option, you can simply use the Registry table. Such changes will automatically be rolled back if the installation aborts.

Of course all of the above only applies if the abort happens during the script execution (between InstallInitialize and InstallFinalize) which is the only place where you should modify the target machine.