I have an InstallShield Basic MSI project which builds both 32-bit and 64-bit installers using Release Flags mechanism to build the different packages with the correct Template Summary, etc. One of my Components is an explorer.exe shell extension, so in order for this to work it needs to be registered in the 64-bit node in the registry when installed on windows 64-bit, NOT in the Wow6432Node. However, because this is a 32-bit Component to Windows Installer it will get registered as such and go down the Wow6432Node. I am told by InstallShield that this is native Windows Installer behavior and there is really no way around this other than Custom Actions (which I have already resorted to).
Do I have to resort to running regasm? This is what I currently do however I would rather not use Custom Actions for something like this. Also, it appears that other products have the same pattern: a 64-bit shell extension, however installed down program files (x86). I see TFS Power Tools and WinZip doing this for example. For these products, I do NOT see regasm.exe running so I assume they have some other mechanism for this.
Any ideas?
Did you try to set msidbComponentAttributesDisableRegistryReflection (Component table) attribute for that component?
Related
I have my contextmenu shell extension dll. I have used Heat.exe to create component for my dll and in install it works completely fine.
But I am not able to register my dll using wix installer.
I have tried various options and nothing is working.
If I try to do manual registration using regasm.exe /codebase Myfile.dll it works.
Regasm /regfile ( and therefore heat or InstallShield ) has a known behavior of not writing out user registration data. In this situations you need to install your software on a VM and use a tool to capture the registry before and after running regasm. Then perform a difference report to see what was changed. Take that and author it into your WXS.
Finally reset the VM and run your new install and verify that it worked.
So we've got this 32-bit software package that is installed on both Win XP and Win 7 machines.
The current issue that I'm looking at is that when installing part of the package, registry values are written to add an executable in the package to the windows context menu. These registry values are part of a wix fragment that is generated by heat from a dll that is part of the process (ie. a dll of the executable).
The problem is that while it works on windows xp embedded, on windows 7, not only does the application NOT show up in the context menu, it also breaks something so that the "New Folder" option is removed from all context menus. Uninstalling the application doesn't work, but it can be fixed by adding the registry settings from this site: http://social.technet.microsoft.com/Forums/en-IE/w7itprogeneral/thread/97de8a2a-12f2-4381-a409-a78f4ae551cf
Of course when you install a new build, then it gets wiped away again, and as developers, sometimes we're installing and uninstalling 5-6 builds a day. I've confirmed that it is those particular registry settings by removing them from the installer and building and installing it, and the "New Folder" option happily stays where it is.
So my question is: is there a problem with heat generating valid registry values to write for a 32-bit application/dll to be added to the context menu on windows 7? (for complete disclosure, I'm using win7 64-bit, but we've had the same issue on win7 32-bit, but we haven't tried vista)
Heat simply captures the registry keys written during the DllRegisterServer() call. If you are not getting the registry keys you expect, then look at the DllRegisterServer() code to see what it is doing. Also, you may find it more useful to capture the registry keys once, verify they are correct then not use heat.exe any longer.
That's my preferred approach.
I'm using WiX to deploy my application. This application uses a registry key which is shared between x64 and x86 processes. Thus it must not use the Wow64Node. The application uses the KEY_WOW64_64KEY flag to achieve this.
But how can this be done using an MSI build with WiX? Currently I use an x86 and an x64 version of the installer, but that gives me a large overhead. Is it possible to disable registry redirection in WiX? I found the DisableRegistryReflection attribute, but that does not seem to have influence on redirection. Another idea would be to merge the two installers into a single file, like it is possible with languages. But I have in mind that that's not supported.
This could be done with an unified 32/64-bit package, but WiX doesn't support it. Some commercial setup authoring tools support it.
When using separate packages, 32-bit installers will use the 32-bit location on 64-bit systems. So to avoid registry redirection you should distribute a 32-bit package for 32-bit systems and a 64-bit package for 64-bit systems.
In 64-bit installers the registry entry component needs to be marked as 64-bit. In WiX you can do this by setting Win64 to "yes" for your registry components.
I created an installer for my AnyCPU DLLs. I've marked my assemblies with teh Assembly=.net directive in my project as well. The installer seems to be able to register the COM servers successfully on my XP 32bit machine, but fails to do so in my Windows7 Machine. I did run the installer in admin mode. Also I looked up the Win764 registry and found those CLSIDs in the reigstry. So looks like the MSI did put some entries in the registry but somehow they are not being recognized as valid COM Server entries (OLE Viewer also didnt enumerate my server).
Any idea why this would happen? Any extra config do I need to add to my project?
thanks
Apparently you need to compile your msi as a 64-bit native binary to have the dlls registered in 64 bit mode.
I have a C++ activex control that I need to make an installer for. It needs to drop the dll and make some registry keys.
I have about 6 .RGS files which I made for self-registration via regsvr32, which work.
To do an installer I am manually porting the RGS scripts into the visual studio 2008 windows installer registry GUI. I feel like its not possible to do an exact port (e.g. RGS keywords like ForceRemove).
Isn't there a way to generate these files from the IDL file? Am I doing this wrong?
SelfReg is not a best practice in an MSI install because it's out of process and fragile. Visual Studio 2008 Installers are limited but you should be able to set the Register property to vsdrfCOM instead of vsdrfCOMSelfReg. This will cause the COM meta data to be harvested from your DLL and authored natively in MSI.
After you build your MSI, you should notice the SelfReg table is empty and a serious of automatically authored rows in the Registry table for you COM data.
Note: VDPROJ is kind of flakey at extracting this COM so it may not work. You might have to consider a stronger tool such as InstallShield or Windows Installer XML.
You are doing it wrong. The .rgs files are there so that the component can install itself. Any installer supports letting a component install itself. A Visual Studio Setup project for example, set the Register property.