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
- :
- Custom Action to Rewrite ARP DisplayVersion in the Uninstall Key...
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
‎Sep 14, 2010
04:00 PM
Custom Action to Rewrite ARP DisplayVersion in the Uninstall Key...
Hi there,
In our old Wise installer, we used to rewrite the DisplayVersion in the Uninstall Registry key via Custom Action. The ProductVersion would be something like 1.2.345, but the actual version known to our Support Department that was released mibht be something like 1.2.0.9. The later is what they like to see in ARP to tell what actual software version they have installed not Installer version.
So, Wise has a utility where you could create WiseScript custom actions, which generated little .exe's. We simply used to grab the ProductCode property and set the DisplayVersion of its Uninstall key to a preset Property containing a value like that described above, 1.2.0.9.
We're going to need this to occur in our newly rebuilt installs using InstallShield 2010 and I'm just wondering if there is a better way to do it. I'm thinking of writting a C++ dll to grab the property values I need and write what is required to the registry. The only problem is I'm no C++ guru and I don't know if code to make registry writes would be heavy lifting for me.
Is there any other way to tackle this problem? What would you do? I know some don't like the idea of managed code Custom Actions, but .NET Framework is a prerequisite so I know the runtime will be there. Is there a way to do this with a VB.NET .dll maybe?
Any tips, pointers, etc would be Greatly appreciated.
In our old Wise installer, we used to rewrite the DisplayVersion in the Uninstall Registry key via Custom Action. The ProductVersion would be something like 1.2.345, but the actual version known to our Support Department that was released mibht be something like 1.2.0.9. The later is what they like to see in ARP to tell what actual software version they have installed not Installer version.
So, Wise has a utility where you could create WiseScript custom actions, which generated little .exe's. We simply used to grab the ProductCode property and set the DisplayVersion of its Uninstall key to a preset Property containing a value like that described above, 1.2.0.9.
We're going to need this to occur in our newly rebuilt installs using InstallShield 2010 and I'm just wondering if there is a better way to do it. I'm thinking of writting a C++ dll to grab the property values I need and write what is required to the registry. The only problem is I'm no C++ guru and I don't know if code to make registry writes would be heavy lifting for me.
Is there any other way to tackle this problem? What would you do? I know some don't like the idea of managed code Custom Actions, but .NET Framework is a prerequisite so I know the runtime will be there. Is there a way to do this with a VB.NET .dll maybe?
Any tips, pointers, etc would be Greatly appreciated.
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 14, 2010
06:56 PM
I have to rewrite the ARP version for our software as well. I am currently using an InstallScript based CA and it's been working well. You can write it in C++ or VBScript if you want. I'm not sure about using managed-code custom actions since our application does not bundle the .net framework by default.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 14, 2010
08:47 PM
Hmmm, an InstallScript Custom Action? I might have to give that a look as well. Do you just run it in the Deferred Sequence after RegisterProduct?
All I would need it to do is grab the ProductCode and set the DisplayVersion to the value held by our Public Property ADDREMDISPLAYVER. How involved is your IS CA?
Also, can I handle the 64 bit registry hive as well as I'm not sure where the ARP info/Uninstall key is written based on architecture? In othere words I don't know if I would need to write a second CA to handle 64 bit registry or not.
I read that you cannot use InstallScript to grab property values in the deferred sequence...
Does this mean I can write the action and schedule it in the Immediate Sequence after Register Product?
All I would need it to do is grab the ProductCode and set the DisplayVersion to the value held by our Public Property ADDREMDISPLAYVER. How involved is your IS CA?
Also, can I handle the 64 bit registry hive as well as I'm not sure where the ARP info/Uninstall key is written based on architecture? In othere words I don't know if I would need to write a second CA to handle 64 bit registry or not.
I read that you cannot use InstallScript to grab property values in the deferred sequence...
Note: Note that the MsiGetProperty and MsiSetProperty properties cannot be used for deferred InstallScript custom
actions, which do not have access to the active .msi database and do not recognize any Windows Installer properties.
They can access only the information that has been written into the execution script.
Does this mean I can write the action and schedule it in the Immediate Sequence after Register Product?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 16, 2010
01:27 PM
Here's what I did and here's the problem....
I've only tested this on 32 bit, but here's the InstallScript code that did up date the Uninstall\DisplayVersion registry value...
Like I said this does update the value I need, however there is an issue. It is left behind on uninstall. Does IScript set a ref count or something? Is there another IScript registry function to only update the value, maybe?
I guess I could add another function to the script to remove and call via Custom Action on uninstall, but I don't know that that would be the best way to do things.
I would simply like to update the value to display a different version and have it uninstall normally as if no edit was made (if that's possible).
Any thoughts, guidance, hints appreciated!
Thanks much in advance!!
I've only tested this on 32 bit, but here's the InstallScript code that did up date the Uninstall\DisplayVersion registry value...
function ARPDisplayVersion(hMSI)
// To Do: Declare local variables.
STRING strProdCode, strOurVersion;
NUMBER numSize;
begin
// To Do: Write script that will be executed when MyFunction is called.
numSize = 256;
// OURVERSION property passed to Execute sequence via CustomActionData
MsiGetProperty (hMSI, "CustomActionData", strOurVersion, numSize);
MsiGetProperty (hMSI, "ProductCode", strProdCode, numSize);
RegDBSetDefaultRoot (HKEY_LOCAL_MACHINE);
// Write the values to the registry. Root set above since HKCR is the default of following function...
RegDBSetKeyValueEx ("Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\" + strProdCode, "DisplayVersion", REGDB_STRING, strOurVersion, -1);
end;
Like I said this does update the value I need, however there is an issue. It is left behind on uninstall. Does IScript set a ref count or something? Is there another IScript registry function to only update the value, maybe?
I guess I could add another function to the script to remove and call via Custom Action on uninstall, but I don't know that that would be the best way to do things.
I would simply like to update the value to display a different version and have it uninstall normally as if no edit was made (if that's possible).
Any thoughts, guidance, hints appreciated!
Thanks much in advance!!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 16, 2010
01:52 PM
Here's another part of the puzzle and I guess this just shows how much I don't know about using InstallScript for Custom Actions.
Just for kicks, I went ahead and added a function to the same Setup.rul file that contains the registry set function. Now, when I run the full install, it seems that even though the Custom Action that calls the key delete function is conditioned as REMOVE~="ALL", it still runs and actually deletes the key on install.
Do I need two separate script files for the tasks to update a key value then delete that key on uninstall? I'm just wondering why the delete function is being called when the Custom Action that calls that function should only run on uninstall.
I have two export prototype statements to designate both as entry point functions. Is that incorrect?
Any help appreciated!!
Just for kicks, I went ahead and added a function to the same Setup.rul file that contains the registry set function. Now, when I run the full install, it seems that even though the Custom Action that calls the key delete function is conditioned as REMOVE~="ALL", it still runs and actually deletes the key on install.
Do I need two separate script files for the tasks to update a key value then delete that key on uninstall? I'm just wondering why the delete function is being called when the Custom Action that calls that function should only run on uninstall.
I have two export prototype statements to designate both as entry point functions. Is that incorrect?
Any help appreciated!!