cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Paul_Jones
Level 3

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
Labels (1)
0 Kudos

(6) Replies
MichaelU
Level 12 Flexeran
Level 12 Flexeran

Normally you should be able to do this with a static extraction of the registration details. The component option .NET COM Interop causes this to be extracted at build.
0 Kudos
Paul_Jones
Level 3

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
0 Kudos
Christopher_Pai
Level 16

What version of IS are you using? I've done this a bunch of times and the setting is right here in red:
0 Kudos
Christopher_Pai
Level 16

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 )

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.
0 Kudos
Paul_Jones
Level 3

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
0 Kudos
Christopher_Pai
Level 16

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.
0 Kudos