I'm building a MSI that targets both 64 and 32 bit platforms, it contains a dll that is only being registered on 64 os. I'm using a custom action to register and unregister the dll :
when uninstalling the software and if the dll was manually unregistered, Uninstallation fails because the regsvr32 /u fails.
regsvr32 /u /s [InstallPath]filename.dll
how to check whether the dll is registered before launching the custom action.
You shouldn't be building one MSI package for both architectures:
http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
and you shouldn't be running regsvr32. Most installer tools have mechanisms to extract registration info into registry entries so that no code is required to run at install time. Tools that don't do that will still let you add your Dll to the MSI file's SelfReg table, and both these alternatives are better than running regsvr32.
Note that if you are in a 32-bit install, some (if not all) attempts to access the 64-bit folders are going to be redirected to the 32-bit equivalents, another reason for not using regsvr32 and creating separate packages.
Related
When I go to register a dll as an admin on my machine it works fine:
Regsvr32 C:\nameofdll.dll
However when I run it on another machine it fails.
Why is that?
Error codes: Error codes can be looked up using one of these methods.
Regsvr32.exe - Admin Rights Required: As far as I know self-registration requires admin rights since it registers the DLL per-machine - or in other words in the HKLM / HKCR sections of the registry (HKCR is a view into a part of HKLM and a merge from sections of HKCU - in other words it is an "emergent view" from both HKCU and HKLM). Now I see this answer which seems to indicate that there are ways to register COM servers per user? It doesn't work for my test OCX files using this method. I did not try the custom registration EXE from codeproject.
MSI - Per-User COM Registration: Windows Installer - on the other hand - is able to install COM servers per-user for setups that install per-user. Per-user setups are bad for a number of reasons (serviceability, upgrading, patching, various limitations), but that is another story. If you enable Installshield's COM Extract On Build as I showed in another answer, the COM data is added to your MSI in a way that ensures that the COM server can be registered per-user - if the setup is installed per-user, or per-machine if the setup is installed per-machine. This is the standard way to register COM files using Windows Installer.
Bitness: Other problem causes are possible, such as the mentioned "bitness" of the COM server. I have encountered very few x64 COM servers, but they are problematic to deal with using WiX for example. As far as I know the WiX 3.11 release does not support x64 COM servers for extraction. Similar problems could exist in Installshield - I don't know.
Support Page: On a 64-bit version of Windows operating system, there are two versions of the Regsv32.exe file:
The 64-bit version is %systemroot%\System32\regsvr32.exe
The 32-bit version is %systemroot%\SysWoW64\regsvr32.exe
Lacking Dependencies: Self-registration can also fail if there are lacking dependencies for the file in question. You can use a tool such as dependency walker to check, or you can monitor with procmon or any number of scanner tools (have a quick skim). Note that it is also possible that you lack a "language dll" for the COM server. For example: MyApp-English.dll. Such a file should be located next to your main COM server file MyApp.dll or MyApp.ocx to allow registration to work correctly.
Oddities: Numerous other problems can be seen. Ranging from licensing issues, COM interoperability with .NET (regasm.exe), interference from weird security policies, security software interference - anti virus etc... To any number of other specific and rare factors.
Warning: I have seen self-registration perform illegal actions and change core system values during the self-registration process - without any warning or explanation. Hence the recommendation to avoid
self-registration during deployment whenever possible.
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?
I'm using Visual Studio 2010 to build a MSI consisting of several DLL files set to register using vsdrpCOMSelfReg. There are also several Windows services that are installed using custom actions. My target machine is running Windows 32bit embedded standard.
My previous development box ran Windows 7 64 bit and I could build and install this MSI with no problem. I recently changed over to Windows 8 Pro, and when I build the MSI using the exact same code base I get "failed to register" errors on my DLLs, which then causes the services to fail installing.
I have a "Privileged" launch condition in the MSI that passes for both versions, so it looks like the required permissions are there.
If I set the DLL files to "vsdrpCOM" I can successfully register after the fact using regsvr32, but my services can't install because they rely on those DLLs being registered to complete their own installation.
What am I missing? What changed with DLL registry beween Windows 7 and Windows 8?
The usual cause for this is missing dependencies. ComSelfReg requires your Dlls to load and run during the install. If you have included the VC++ runtime support as merge modules and they install in WinSxS then they are not available until after your selfreg code needs to run. The symptoms are exactly those you'd get when the VC++ runtime is being installed from merge modules and do not already exist on the system - failure during the install and success with regsvr32 after the install.
In general you should look at using a tool that doesn't require code to install services. All the major install tools populate the ServiceInstall and ServiceControl tables in the MSI file because MSI will install services just fine, but VS setups don't use them for some reason.
The problem was in the dependencies automatically pulled in when I added the DLL Project Outputs. One of the detected dependencies was IPHLPAPI.DLL, pulled from C:\Windows\System32. This DLL was then copied into the application directory. In my install of Windows 8 Pro, IPHLPAPI.DLL is version 6.2.9200.16420. In Windows 7, this file is version 6.1.7600.16385.
I'm guessing my assemblies were referencing the Windows 8 version since that was in the local directory, and this caused registration and/or runtime errors. I excluded IPHLPAPI.DLL from the installer and everything is now running correctly, referencing the file in System32.
I'd like to create an installer package to install registration-free COM components (with manifest files included). This would be more or less a self-extracting archive to place some files in a target directory given as commandline argument, but it would also need to check or install some other redistributables like VC++ or DirectX.
The package is supposed to be used in another applications's installer as some kind of redistributable package itself. It should not be registered in the "Program and Features" dialog of Windows but has to be removed with the application. Ideally there should be no changes to the Windows registry.
So far I haven't been very successful. Can anyone please provide me with some hints regarding this use case?
You've got about a dozen different questions in that one question. Start with just creating a simple MSI that successfully installs your files and your manifest. Create a COM client to test it. You can also put AppSearch and LaunchConditions in your MSI to detect your dependencies and not allow installation if they are missing.
That's about all you should have to do for this simple question. As for the other questions.... if you are a redistributable and someone else is silently installing you then it's their job to handle the installation of the other redistributables. Also if they don't want you listed in Programs and Features they can pass the ARPSYSTEMCOMPONENT=1 to your installer and you won't be listed. If they want to uninstall you when they uninstall themselves, that's their problem not yours.
If you are really creating a redistributable to be used by other products, sometimes a merge module is the appropriate solution. They build their MSI files and include your merge module.
Otherwise, reg-free COM is in theory an easy install because you're just installing manifest files and Dlls etc. However I don't understand how that could be used by other apps because (IIRC) a client app exe needs your manifest and Dll in their install folder, so how can they do that when they are not installed yet? Or even if they are installed how can you find them? So that goes back to the merge module idea so they include your merge module and install an exe, your manifest and your Dll in the same location. When they uninstall so do your files.
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.