471,317 Members | 1,506 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,317 software developers and data experts.

Installation Problems with COM Interop

Hello All,

I have created a C# project that sets "Register for COM Interop" to true,
and sets the ProgId and Guid attributes for the class. I then use this
control inside VB6.

This all works correctly on my development machine (oh no, one of those!),
creating a DLL and a tlb on each compile, and setting the entries in the
registry. It also appears to work correctly on a separate Build machine,
where the output then gets packaged for installation using InstallShield 11.
The .NET output gets packaged in a merge module, which is then included in a
number of installations (both .NET and COM).

When it gets installed, there are no installation errors. However, the
registry settings (ProgID and CLSID, for example) are not being set, and
therefore the control cannot be seen from a COM-based project using late
binding. It works fine for a .NET test container, but since that's not
registry-dependant, I am not surprised.

I am not sure if this is a problem with the way I am setting up
InstallShield, if there is an InstallShield issue, or if it is in the .NET
code itself.

If anybody has any ideas or experience with this, I'd appreciate any ideas.

Thanks,
pagates
Jan 10 '06 #1
2 4400
pagates,

You said that you are using this "control" inside of VB6. By that, do
you mean an ActiveX control? If so, you should be warned that MS doesn't
support exporting ActiveX controls from .NET.

That being said, the registry settings are created when you run the
assembly through regasm, which will read the attributes and create the
assembly. That being said, you probably need to direct InstallShield to do
the same, assuming it doesn't have any facility to do it already.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"pagates" <pa*****@discussions.microsoft.com> wrote in message
news:6B**********************************@microsof t.com...
Hello All,

I have created a C# project that sets "Register for COM Interop" to true,
and sets the ProgId and Guid attributes for the class. I then use this
control inside VB6.

This all works correctly on my development machine (oh no, one of those!),
creating a DLL and a tlb on each compile, and setting the entries in the
registry. It also appears to work correctly on a separate Build machine,
where the output then gets packaged for installation using InstallShield
11.
The .NET output gets packaged in a merge module, which is then included in
a
number of installations (both .NET and COM).

When it gets installed, there are no installation errors. However, the
registry settings (ProgID and CLSID, for example) are not being set, and
therefore the control cannot be seen from a COM-based project using late
binding. It works fine for a .NET test container, but since that's not
registry-dependant, I am not surprised.

I am not sure if this is a problem with the way I am setting up
InstallShield, if there is an InstallShield issue, or if it is in the .NET
code itself.

If anybody has any ideas or experience with this, I'd appreciate any
ideas.

Thanks,
pagates

Jan 10 '06 #2
Hi Nick,

Thanks. After trying many combinations of "Self Register" (which will
always fail) and "Extract COM at Build" in InstallShield, I finally found a
setting called ".NET COM Interop" in InstallShield. After setting that to
"Yes", the components registered correctly.

Thanks Again,
PAGates

"Nicholas Paldino [.NET/C# MVP]" wrote:
pagates,

You said that you are using this "control" inside of VB6. By that, do
you mean an ActiveX control? If so, you should be warned that MS doesn't
support exporting ActiveX controls from .NET.

That being said, the registry settings are created when you run the
assembly through regasm, which will read the attributes and create the
assembly. That being said, you probably need to direct InstallShield to do
the same, assuming it doesn't have any facility to do it already.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"pagates" <pa*****@discussions.microsoft.com> wrote in message
news:6B**********************************@microsof t.com...
Hello All,

I have created a C# project that sets "Register for COM Interop" to true,
and sets the ProgId and Guid attributes for the class. I then use this
control inside VB6.

This all works correctly on my development machine (oh no, one of those!),
creating a DLL and a tlb on each compile, and setting the entries in the
registry. It also appears to work correctly on a separate Build machine,
where the output then gets packaged for installation using InstallShield
11.
The .NET output gets packaged in a merge module, which is then included in
a
number of installations (both .NET and COM).

When it gets installed, there are no installation errors. However, the
registry settings (ProgID and CLSID, for example) are not being set, and
therefore the control cannot be seen from a COM-based project using late
binding. It works fine for a .NET test container, but since that's not
registry-dependant, I am not surprised.

I am not sure if this is a problem with the way I am setting up
InstallShield, if there is an InstallShield issue, or if it is in the .NET
code itself.

If anybody has any ideas or experience with this, I'd appreciate any
ideas.

Thanks,
pagates


Jan 10 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Shiro | last post: by
reply views Thread by Craig G | last post: by
8 posts views Thread by John Olbert | last post: by
5 posts views Thread by =?Utf-8?B?U3R1YXJ0?= | last post: by
2 posts views Thread by =?Utf-8?B?R3JlZw==?= | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.