#1
|
|||
|
|||
Read registry
I am seeing some weird behavior reading the registry on one server, other servers seem fine but this one is strange
I am trying to find if a software package is installed and I am searching in SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstal l\ But the values returned are not from this location but from SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVers ion\Uninstall Why is the Wow6432Node being returned and I am not asking for it. The build machine is 2003 x86 server the server I am calling is 2008 R2 x64. Now this works fine on other 2008 R2 x64 servers but for some reason this one is not returning the right node. I am using the 32 version of VB8 see below Visual Build Professional 8.1 Registered to: ACE USA - Southbury, CT (1-site license) Windows Version: 5.2.3790.2.0 Install path: C:\Program Files\VisBuildPro8 HideConsole.exe version 1.0.0.0 SftPrintPreview_IX86_U_20.dll version 2.04 VisBuildCmd.exe version 8.1.0.1 VisBuildPro.exe version 8.1.0.1 VisBuildAct.dll version 8.1.0.2 VisBuildCore.dll version 8.1.0.1 VisBuildDotNET.dll version 8.1.0.0 VisBuildExt.dll version 8.1.0.1 VisBuildMisc.dll version 8.1.0.1 VisBuildMS.dll version 8.1.0.2 VisBuildMS2.dll version 8.1.0.1 VisBuildNet.dll version 8.1.0.1 VisBuildSvr.dll version 8.1.0.2 VisBuildSvr.Interop.dll version 1.0.0.0 VisBuildVCS.dll version 8.1.0.1 |
#2
|
|||
|
|||
I'm not sure. I'm guessing there's some Windows configuration setting different on that particular machine?
This articles indicates that with 2003 SP1 and later, the 64-bit view will be always accessed, unless the KEY_WOW64_32KEY flag is used (not possible from 32-bit Visual Build): http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx Although it's not entirely clear if the Windows 2003 behavior is for 2003 and later or just Win2003. So it could mean that for a Win 2008 remote machine, the first statement applies (If the client is a 32-bit application, it accesses the 32-bit registry view. If the client is a 64-bit application, it accesses the 64-bit registry view). One thing you might try would be updating the client to 2003 SP1, since the behavior changed with that version (but this wouldn't explain why it works on all remote 2008 boxes except one). Another option might be to use 64-bit Windows + 64-bit Visual Build on the client. |
#3
|
|||
|
|||
Sorry my build machine is at SP2, is there something else I can look at?
|
#4
|
|||
|
|||
I just compared one of my other 2008 server that works, the strange is that it must be looking int he same place under SOFTWARE\Wow6432Node\Microsoft\Windows.
The only difference here is that for some reason our msi are installing and storing there uninstall information to the SOFTWARE\Wow6432Node\Microsoft\Windows on the good server but the server that is an issue the MSI is installing and storing the uninstall information under the SOFTWARE\Microsoft\Windows. Is there reason that an MSI would store its uninstall information in one place or the other? |
#5
|
|||
|
|||
I believe that an MSI package can be either 32- or 64-bit, and the package type determines the registry view that is used.
http://blogs.msdn.com/b/heaths/archi...itectures.aspx Another option might be to use VBScript/WMI: http://www.google.com/search?q=vbscr...egistry+64-bit |
#6
|
|||
|
|||
In the mean time is there a way in the Read Registry action to be specific on where to look for the registry, this way I can check both location for the installer to see if it exists.
|
#7
|
|||
|
|||
See the 64-bit/32-bit registry view options for the action.
http://kinook.com/VisBuildPro/Manual/readregistry.htm From the document previously mentioned, it's unclear what the Windows registry API implementation does for 32-bit clients accessing a remote 64-bit computer. The behavior you're describing is consistent with the first statement at http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx (If the client is a 32-bit application, it accesses the 32-bit registry view). You might try checking the Access 64-bit registry view if not already checked. Otherwise, you may need to use the 64-bit version of Visual Build on 64-bit Windows client to access a remote 64-bit registry view. |
#8
|
|||
|
|||
The option to select Access 64-bit registry view is grayed out. Is there a reason I cant access this checkbox?
|
#9
|
|||
|
|||
Oh yeah -- that option is disabled on x86 Windows, since it is meaningless for local registry access, and we didn't anticipate the possibility of accessing a remote 64-bit registry view from 32-bit Windows. We'll see about testing and enabling that scenario. For now, you may need to use VBScript/WMI to access a remote 64-bit registry view from Visual Build on 32-bit Windows.
http://www.google.com/search?q=vbscr...egistry+64-bit |
#10
|
|||
|
|||
Download, extract and copy the files in http://www.kinook.com/Download/VisBuild82_x86_patch.zip to the System folder within your 32-bit Visual Build install path to enable and use the 64-bit option for remote registry access.
|
#11
|
|||
|
|||
Cool I will try it but I have to create a VM in order to test this out, we have 150 apps prepared for the current build server and I dont want to interupt that process.
I will keep you posted on my testing, again thanks for helping with this! |
#12
|
|||
|
|||
This works Great!!!!! I was able to recreate the issue in some VM's and its working now.
I was reading more into the help file and I was wondering, if I have a x64 build machine, running either 32 or 64 Visual Build will I be able to access either the 32 bit or 64 hive on a remote 64 bit machine? I assume that if I access a 32 bit machine it should just work. Another thought, if there was a way on the "Step Starting Event" to set some macro's to determine what hive it access that might be helpful as well. As always I am so impressed with the level of support you provide! |
#13
|
|||
|
|||
You can access the 32- and 64-bit registry views from the 32- and 64-bit editions of Visual Build. By default, the 32-bit edition accesses the 32-bit registry view, but can access the 64-bit view on 64-bit Windows by checking the Access 64-bit registry view option. And the 64-bit edition accesses the 64-bit view by default, but it can access the 32-bit view by checking the Access 32-bit registry view option.
http://www.kinook.com/VisBuildPro/Ma...adregistry.htm By "a way on the "Step Starting Event" to set some macro's to determine what hive it access," if you mean that you want to dynamically check the 32-/64-bit options based on a macro, you can use a field override to do that. http://www.kinook.com/VisBuildPro/Ma...htsub=override |
#14
|
|||
|
|||
Assigning a Macro to a checkbox is exactly what I was looking for, thanks, that's perfect.
Will the new DLL's you provided be put into the main application moving forward? Or will I need to keep these for future releases? |
#15
|
|||
|
|||
This has been incorporated into the latest build (v8.3).
|
|
|