"Chris Mullins" <cmullins@yahoo.com> wrote in message
news:%23Wmnb35$GHA.4292@TK2MSFTNGP02.phx.gbl...
>I need to write to the 32-bit registry, and need to do so from a 64-bit
>MSI. It never occurred to me that this would be difficult...
>
> I have an application that installs some 64-bit binaries for development
> use
> in Visual Studio 2005. As such I want them to appear in the .Net
> References
> menu when someone attempts to "Add References" to their project.
>
> Doing this means (normally) writing to the registry key:
>
> HKLM\Software\Microsoft\.NetFramework\v2.0.50727\AssemblyFoldersEx\MyNewBinaries,
> with a default string value of C:\Program Files\MyBinaries.
>
> However, since this is a 64-bit installer, and Visual Studio 2005 is only
> 32-bit, the actual registry key I want to install is:
>
> HKLM\Software\WOW6432Node\Microsoft\.NetFramework\v2.0.50727\AssemblyFoldersEx\MyNewBinaries,
> with a default string value of C:\Program Files\MyBinaries.
>
> All of which seems simple enough. However, when I run the installer, the
> registry key is installed in the 64-bit location instead of the explicitly
> specified 32-bit.
>
> If I log verbose output from the msiexec.exe, it thinks it installed the
> key
> in WOW6432Node. However, the result is in the normal Software node. I
> realize that 32-bit installers see only the WOW6432Node as the normal
> node,
> but it was my understanding that a 64-bit installer would have access to
> the
> entire registry. Instead it seems to translate a write to the WOW6432Node
> as a write to the normal Software node. I posted the project to the web
> so
> you can see of yourselves. Any help would be appreciated.
>
>
http://www.coversant.com/downloads/Setup1.vdproj.RENAME.txt >
> (that's really a standard vdproj file, but I'm too lazy to add in the
> extensions to IIS, so I just renamed it).
>
> I can write an installer class to work around this issue, but I was
> wondering if there was a more direct solution.
>
> --
> Chris Mullins, MCSD.NET, MCPD:Enterprise
>
http://www.coversant.net/blogs/cmullins >
This is strictly MSI related. Follow-up in microsoft.public.windows.msi.