It appears that regasm.exe is only capable of registering a COM-visible assembly in HKLM, for the whole system. Is there a way to do it for the logged-in user only, without an MSI installer?
I've considered using regasm to dump a .reg file, and then processing that to add the registry entries myself... don't want to reinvent the wheel if I can avoid it.
Related
I'm using Advanced Installer to try to create an installation package (single EXE setup file) for an MS Project VSTO add-in. I need the installation Type to be Per Machine but when I chose this option and run the setup.exe file, the Add-in will not load for any of the user's on the target machine. The only way I can get it to load is if I change the installation type to Per User, which I don't want.
I'm fairly certain the problem is related to the registry, because the setup.exe is not adding the proper registry keys under HKEY_LOCAL_MACHINE to load the add-in, even though I have it set up to do so:
What am I doing wrong?
There are other things that needs to be done except windows registry keys. For example, you need to specify whether you want to support per-user or per-computer installations.
The Deploy an Office solution by using Windows Installer article describes all the necessary steps for creating per-use and per-machine Office add-in installers. Make sure that you did everything in your installation package.
I created an install shield project for an Excel add-in.
I selected .dll file and the .tlb file to be moved to the GAC (in destination folder) and program files folder
Those files are present in the program files folder
But when I go to Excel, click on tools-> reference, they are not appearing in that list!
I had to manually browse to the location of that .tlb file and select it
What change should i make so that it automatically comes in the references list
This article gives you description of two methods to do the registration with Installshield: Installshield Register.Net DLLs.
I definitely recommend Approach 2 - Run a .bat file to register the files. This approach runs the RegAsm for the install and uninstall processes using a batch file. This will give you control over the registration process, where you know exactly what is done, and you can handle all bitness scenarios 32/64/Wow64. In Approach 1 you don't, as stated in the article:
For some reason, perhaps that I am installing a 32bit component on a 64bit machine, this didn’t work as expected. [...] some DLL’s perform post registration actions the run when you run RegAsm.exe VirtualCam.dll /nologo /codebase but don’t get captured when you run RegAsm.exe VirtualCam.dll /nologo /codebase /regfile
If possible I would recommend switching to a different installation package creator, that supports run operations and gives better control over the process than using a batch.
*As it's not a native COM dll but a dotNet dll exposed to COM, there's no need for regsvr32 registration.
I have some dll files that should be assembled and registered into a msi file. I want to read the relative information from the dll file and write these items into msi file directly. But how can I read these registry information from dll file? What information should I write into msi registry table? Is there any way to do that?
A lot of commercial setup authoring tools can extract the DLL registration information. For example, you can try Advanced Installer.
Another approach is to register your DLLs manually with the appropriate command line tool. Using an installation repackager, you can capture this process into an MSI. This way you can catch all the registry entries created by the registration process.
Background to Question
I am currently in the process of trying to put together a means of distributing a new project I am working on which requires that a COM exposed .NET DLL be registered on the user's system and as I am new to WiX and making the move to it for this I am trying to keep things as simple as possible.
The Problem
The big issue with my DLL registration is that regasm sets the default value of the InProcServer32 key to "mscoree.dll", but my DLL can only seem to be instantiated when the full path to it is used, e.g. "C:\Windows\SysWow64\mscoree.dll"
Currently I have a custom action in my setup project (which I want to abandon to use WiX) which will call the SearchPath API to find the full path to mscoree.dll and overwrite the default value with the full path, so that the DLL can be instantiated without any issues.
Proposed Solution / Question
As I am new to WiX I have had the idea of preparing a .reg file that will contain all the necessary information to go into the CLSID tree and then having WiX execute that some how.
My question is:
Are there any inherent flaws by registering a DLL this way?
As the main reason I am trying to find work arounds here is the mscoree.dll issue, is there any native means of doing this in WiX?
Take a look at the WiX program called "Heat". This can "harvest" your DLL including registry information related to the RegAsm / COMVisible parts. You can then snip this code and work it into your wxs file.
You can also use Regasm /regfile and then manually transform that information into RegistryValue elements.
With regard to your path problem, use the SystemFolder property.
[SystemFolder]mscoree.dll
If you mark your install as 32bit (x86) this will automatically resolve to the SysWow64 folder when run on a 64bit OS and the System32 folder when run on a 32bit OS.
I try to register dll (ActiveX) for non-admin user using MSI.
To create registry settings I have register the dll in admin mode, then exported the relevant registry entries and renamed all HKLM to HKCU.
When I install it for non-admin user all works fine. But when I use the same settings with admin user, there is a problem of discovering TypeLib.
What should be changed in the registry entries to work both for admin and non-admin user, when the registration done under HKCU?
Thank you
If your entries are really registered under HKCU, it will work. What MSI installer are you using? There should be a way to specify that it should install in user mode.
Are you letting the dll self-register or having the msi register the dll? it is best practice to have the MSI do it, but it's more of a pain. If you're having the .dll self-register you need to make sure that the dll registers in HKEY_CURRENT_USER and not HKEY_LOCAL_MACHINE, which ATL does by default.
If you built it in VS2008 with ATL, you'll want to add:
AtlSetPerUserRegistration(true);
to your DllRegisterServer and DllUnregisterServer.
Anyway, those are some things to look for. You can use Process Monitor and watch the Reg commands to see exactly what is happening; something somewhere is writing to HKLM.