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
- :
- Re: Accessing HKLM\Software\Wow6432Node?
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
‎Feb 10, 2011
02:49 PM
Accessing HKLM\Software\Wow6432Node?
Hi all,
I've seen several posts on this subject, but I don't know if its really doable. we are moving from a 32 bit application to a 64 bit application/installation. I want to be able to access some values in HKLM\Software\Wow6432Node\OurApp\Subkey that were written during the live of the 32 bit app. I would use these to populate some serialization text boxes on a dialog.
I can't for the life of me get the values? I've tried toggling the look in the 64 bit registry option, but neither setting works.
Can this be done?
I've seen several posts on this subject, but I don't know if its really doable. we are moving from a 32 bit application to a 64 bit application/installation. I want to be able to access some values in HKLM\Software\Wow6432Node\OurApp\Subkey that were written during the live of the 32 bit app. I would use these to populate some serialization text boxes on a dialog.
I can't for the life of me get the values? I've tried toggling the look in the 64 bit registry option, but neither setting works.
Can this be done?
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 11, 2011
03:08 AM
Hi
What method are you trying to access the Wow6432Node key? Is this scripted?
Is your MSI pure 32bit running on 64bit machine?
This kind of thing is a right pain (thank MS!) but there are ways of achieving it
What method are you trying to access the Wow6432Node key? Is this scripted?
Is your MSI pure 32bit running on 64bit machine?
This kind of thing is a right pain (thank MS!) but there are ways of achieving it
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 11, 2011
08:00 AM
Ah, yes good details to have left out.
It is a 64 bit installation that wants to access the WOW6432Node in HKLM.
I'm currently trying to use the System Search view in IS 2010.
I understand that I can write a CA dll, I guess, that could search the hive and set the running .msi properties I need, but C++ is recommended for that. I'm no C++ wiz (or any other programming language for that matter) but I might be able to scrape something together. Can I create a VB.NET dll to do the same or must it me C++?
What I initially tried was add a whole set of Properties to hold the searched/collected data from WOW6432Node. I was then going to set the dialog Properties to these newly created properties if they have been populated.
I would think maybe a .dll would be better. That way, if my original search properties (the ones displayed in the dialog) are not populated, I could fire the .dll Action to search the Wow6432Node.
Does anyone have any code that would get this done? If VB.net will work, that would be preferable.
Thanks for any info.
Any yes, this portion of .msi processing is a pain!!
It is a 64 bit installation that wants to access the WOW6432Node in HKLM.
I'm currently trying to use the System Search view in IS 2010.
I understand that I can write a CA dll, I guess, that could search the hive and set the running .msi properties I need, but C++ is recommended for that. I'm no C++ wiz (or any other programming language for that matter) but I might be able to scrape something together. Can I create a VB.NET dll to do the same or must it me C++?
What I initially tried was add a whole set of Properties to hold the searched/collected data from WOW6432Node. I was then going to set the dialog Properties to these newly created properties if they have been populated.
I would think maybe a .dll would be better. That way, if my original search properties (the ones displayed in the dialog) are not populated, I could fire the .dll Action to search the Wow6432Node.
Does anyone have any code that would get this done? If VB.net will work, that would be preferable.
Thanks for any info.
Any yes, this portion of .msi processing is a pain!!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 11, 2011
12:29 PM
Hmm, how about creating a new vbscript custom action to fetch the registry properties?
It a little bit crude but the custom action script would be something along the lines of:
Dim objShell, strKey1, strKey2
Set objShell = CreateObject("WScript.Shell")
On Error Resume Next
strKey1 = ObjShell.RegRead("HKLM\SOFTWARE\Wow6432Node\InstallShield\16.0\CurrentVersion")
strKey2 = ObjShell.RegRead("HKLM\SOFTWARE\Wow6432Node\InstallShield\AdminStudio\ASLocation")
Session.Property("REGVALUE1") = strKey1
Session.Property("REGVALUE2") = strKey2
This should push the values of your registry keys into the desired Properties (REGVALUE1 etc) which could then be referenced elsewhere in your package.
I think the problem with the system search is that it is essentially returning a True or False value based on the Reglocator table and doesn't return the actual value of the key.
It a little bit crude but the custom action script would be something along the lines of:
Dim objShell, strKey1, strKey2
Set objShell = CreateObject("WScript.Shell")
On Error Resume Next
strKey1 = ObjShell.RegRead("HKLM\SOFTWARE\Wow6432Node\InstallShield\16.0\CurrentVersion")
strKey2 = ObjShell.RegRead("HKLM\SOFTWARE\Wow6432Node\InstallShield\AdminStudio\ASLocation")
Session.Property("REGVALUE1") = strKey1
Session.Property("REGVALUE2") = strKey2
This should push the values of your registry keys into the desired Properties (REGVALUE1 etc) which could then be referenced elsewhere in your package.
I think the problem with the system search is that it is essentially returning a True or False value based on the Reglocator table and doesn't return the actual value of the key.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 11, 2011
12:39 PM
I would have liked to get experience with writing a custom action .dll (in VB.NET preferably) to search the registry and set the properties.
However, this could work because if the registry entries can't be found, the user would just have to enter their serial number, etc the first time they upgrade our old 32 Bit Server app to the new 64 Bit app. In short, it's not a huge deal and although I would have like to try to see if its possible to have a custom action .dll written in VB.NET, the vbscript isn't a big deal.
I remember that vbscript custom actions are frowned upon, but we have a couple in our install presently anyway.
Thanks for the code snippet.
If anyone has successfully written and used a VB.NET custom action .dll, please let me know in which direction to go.
THANKS!
However, this could work because if the registry entries can't be found, the user would just have to enter their serial number, etc the first time they upgrade our old 32 Bit Server app to the new 64 Bit app. In short, it's not a huge deal and although I would have like to try to see if its possible to have a custom action .dll written in VB.NET, the vbscript isn't a big deal.
I remember that vbscript custom actions are frowned upon, but we have a couple in our install presently anyway.
Thanks for the code snippet.
If anyone has successfully written and used a VB.NET custom action .dll, please let me know in which direction to go.
THANKS!