This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: How to register a .Net Com Assembly
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Sep 14, 2011
06:07 AM
How to register a .Net Com Assembly
Hello,
There seem a lot of people with a similar problem to me but I haven't found a solution that works yet.
I have a .Net class library dll which supports Com. The dll is implemented in c#. I would like to know the recommended way of registering this dll using InstallShield.
My current solution is to call "regasm mydll.dll" from within OnFirstUIAfter() and this works, but I think InstallShield should be able to do this for me.
I tried the following, without success:
1. Setting ".NET Assembly" = "Local Assembly", and "Self-Register" = "Yes" in the relevant component properties. This results in the install apparently working - it does not generate any errors and the dll is written to the specified location on the target machine. However the dll is not registered (the registry has not been updated and the client application cannot load it).
2. Setting ".NET Assembly" = "Not a .NET Assembly", and "Self-Register" = "Yes". This results in a dialog appearing during the install saying "The following files did not self-register or unregister: 1. c:\....\mydll.dll. The specified procedure could not be found." - presumably because there is no DllRegisterServer() entry point.
I don't understand why I can register the dll using regasm but not installshield.
Can anyone suggest how I can register the dll using installshield?
Many thanks, Paul
There seem a lot of people with a similar problem to me but I haven't found a solution that works yet.
I have a .Net class library dll which supports Com. The dll is implemented in c#. I would like to know the recommended way of registering this dll using InstallShield.
My current solution is to call "regasm mydll.dll" from within OnFirstUIAfter() and this works, but I think InstallShield should be able to do this for me.
I tried the following, without success:
1. Setting ".NET Assembly" = "Local Assembly", and "Self-Register" = "Yes" in the relevant component properties. This results in the install apparently working - it does not generate any errors and the dll is written to the specified location on the target machine. However the dll is not registered (the registry has not been updated and the client application cannot load it).
2. Setting ".NET Assembly" = "Not a .NET Assembly", and "Self-Register" = "Yes". This results in a dialog appearing during the install saying "The following files did not self-register or unregister: 1. c:\....\mydll.dll. The specified procedure could not be found." - presumably because there is no DllRegisterServer() entry point.
I don't understand why I can register the dll using regasm but not installshield.
Can anyone suggest how I can register the dll using installshield?
Many thanks, Paul
(6) Replies
‎Sep 14, 2011
02:18 PM
Thanks for your reply Michael.
".Net COM Interop" is not present in component options. I can see it in the help, but with my project loaded in the IDE the only visible ".Net Settings" for this component are ".Net Assembly" and ".Net Scan at Build".
How can I find or enable the ".Net COM Interop" setting?
Thanks, Paul
".Net COM Interop" is not present in component options. I can see it in the help, but with my project loaded in the IDE the only visible ".Net Settings" for this component are ".Net Assembly" and ".Net Scan at Build".
How can I find or enable the ".Net COM Interop" setting?
Thanks, Paul
‎Sep 14, 2011
03:40 PM
‎Sep 14, 2011
03:43 PM
You can also run regasm /regfile:foo.reg and then take the resultant reg file and import it into the component as registry data. Tweak the values to reference [#file] file keys and you are done.
There's really nothing that difficult about COM Visible assemblies except for the big gotcha that if you have user authored code in the registration methods that regasm /regfile won't capture it. ( SEE http://msdn.microsoft.com/en-us/library/tzat5yw6(v=vs.71).aspx )
There's really nothing that difficult about COM Visible assemblies except for the big gotcha that if you have user authored code in the registration methods that regasm /regfile won't capture it. ( SEE http://msdn.microsoft.com/en-us/library/tzat5yw6(v=vs.71).aspx )
You can use the /regfile option to generate a .reg file that contains the registry entries instead of making the changes directly to the registry. You can update the registry on a computer by importing the .reg file with the Registry Editor tool (Regedit.exe). Note that the .reg file does not contain any registry updates that can be made by user-defined register functions.
‎Sep 15, 2011
04:06 AM
Thanks for your replies Chris.
I have IS2011. I see your project type is "Basic MSI" whereas mine is "InstallScript". It turns out that if I create a new Basic MSI project then I get the same propertes as in your screenshot, but if I create a new InstallScript project then ".NET COM Interop" is not present.
So my question becomes, what is the reccomended way of installing a .Net DLL that supports a COM interface from an IS2011 InstallScript project? (of which I have 15)
Is the regfile option the best solution?
Many thanks, Paul
I have IS2011. I see your project type is "Basic MSI" whereas mine is "InstallScript". It turns out that if I create a new Basic MSI project then I get the same propertes as in your screenshot, but if I create a new InstallScript project then ".NET COM Interop" is not present.
So my question becomes, what is the reccomended way of installing a .Net DLL that supports a COM interface from an IS2011 InstallScript project? (of which I have 15)
Is the regfile option the best solution?
Many thanks, Paul
‎Sep 15, 2011
05:45 AM
This gets to the heart of the whole procedural vs declarative debate. Since you've choosen an InstallScript project it would be acceptable to call RegAsm during the install to register the types. You could also do it the way we would do it in Windows Installer and extract the registry information and use InstallShield to apply it during the install.
The choice boils down to which do you think will be less fragile? Applying a bunch of registry values or calling an out of process EXE a bunch of times and hoping that the registration code doesn't fail.
I would choose the later but then I also would have choosen MSI.
The choice boils down to which do you think will be less fragile? Applying a bunch of registry values or calling an out of process EXE a bunch of times and hoping that the registration code doesn't fail.
I would choose the later but then I also would have choosen MSI.