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

Install Script Does Not Register .Net COM Assemblies

I can't seem to find a way to get my InstallScript project to register my COM interop .Net dlls on my target machine.

If I use a Basic MSI Script to create the install then everything works properly (once I've manually set the .Net Assembly info on the components to let IS know that the dll is a com-based .net assembly; for whatever reason it doesn't pick that up when I add the dll to the project).

I can't find anwhere in the installscript project to manually change the .net assembly info to let it know that i'ts com-based and needs to register it on the target machine.

Any suggestions?

Doug.
Labels (1)
0 Kudos
(10) Replies
Christopher_Pai
Level 16

Run regasm /regfile to harvest the registry data for the assembly and then work that into a registry set.
0 Kudos
marqdouj
Level 3

Christopher Painter wrote:
Run regasm /regfile to harvest the registry data for the assembly and then work that into a registry set.


Hmmm... seems like that defeats the purpose of having a 'tool'.
In any case, if that is the only way then I'll have to do it (I guess).

Not too impressed with IS lately.

Doug.
0 Kudos
Christopher_Pai
Level 16

It's exactly how it works in Basic MSI only the abstraction (COM Visible=true) tells InstallShield to do this for you at build time. In InstallScript projects it's one more step. The behavior at install time is the same though: the engine (InstallScript vs Windows Installer ) applies registry values.

Personally I think it's an elegant and robust solution. Perhaps the real problem is that you are still using the InstallScript project type. I switched to MSI 10 years ago.
0 Kudos
marqdouj
Level 3

I wanted to use the Install Script project so I could get the Skins; I don't see anyway of doing that in MSI?
0 Kudos
Christopher_Pai
Level 16

InstallScript MSI projects will do both.
0 Kudos
marqdouj
Level 3

I'll try that; thanks.

Doug.
0 Kudos
Christopher_Pai
Level 16

BTW, I just realized from looking at your posting history that you are the person I gave advice to regarding regasm complications.

Please be sure to realize (if you don't already) that when I give advice in threads I don't know your full scenario, history, needs and so on.

I mentioned InstallScript MSI because it supports both but in reality you have to manually author reg data to work around that problem so it doesn't really matter that it supports both.

Also, I don't know how important skins are to you. The themes in a Basic MSI might be good enough for you. Also suite installers might give you a good UI experience. In general I am a purist and make do with the limitations of Native MSI UI in order to keep the installer as simple as possible (KISS).

So I hope I've given you a lot of options and sorry if I can't tell you to do exactly a, b and c.
0 Kudos
marqdouj
Level 3

Not a problem - it's all good, thanks for the help.

I was just a little miffed that the docs (at least the way I read them) indicated that IS would automatically register the .net com dlls on the target machine.

Now that I know what my options are I can move forward.

Doug.
0 Kudos
Christopher_Pai
Level 16

I haven't found anything that says it should support it. The help topic "Component Settings" talks about .NET Settings | .NET COM Interop but says it's for Basic MSI, DIM, InstallScript MSI and Merge Module projects.

There's a Windows Installer topic called "Adding Assemblies to a Package" and it has a bullet that says:

Use the Registry table instead of the Class table when you register COM Interop for an assembly


Hence what IS does in an MSI project. For the InstallScript project it would translate that to a registry set.
0 Kudos
marqdouj
Level 3

I am new to IS so all these different types of projects are getting me confused 😉

I recently switched from another product (they dumped the product line and there was no more support so we switched) where it automatically handled .net com registration. Seems to me that IS is more 'hands-on'; which can be a good thing 🙂

Doug.
0 Kudos