2 VC# COM problems

[Guest]

As the subject suggests, I have two questions about using COM objects in C#. I'm using two different objects, each of which is giving me a problem.

The first object ... we'll call it AppXControl. Here's some Visual Basic 6 code I've written which gets the code connected to the COM object.

Private WithEvents xControl As AppXControl.Control
Private xConnector As New AppXControl.Connector

** This line of code is in FormMain_Load()
Set xControl = xConnector.xMonitor

Basically, you instantiate two classes defined in the COM object. The first is a controller -- this is the actual object that catches triggered events and so on. The second is a connector. You instantiate it, and use xConnector.xMonitor to get an xControl object for use in doing COM with ApplicationX.

Here's the corresponding C# code:

public class Form1 : System.Windows.Forms.Form
{
private AppXControl.ControlClass xControl;
private AppXControl.ConnectorClass xConnector = new AppXControl.ConnectorClass();

....

public Form1()
{
InitializeComponent();
xControl = xConnector.xMonitor;
}

....
}

Here's the problem. In the Form1 Constructor, xConnector.xMonitor is returning an object of type AppXControl ... but what I really need here is an object of type AppXControlClass. The COM object itself has no knowledge of this AppXControlClass, it is created by C# when the object is ported to the .NET framework with tlbimp. Is there any way I can get the AppXControl object instead of AppXControlClass without asking the COM object's vendor to rewrite their code? (Which I doubt they'd do anyway.)

Now on to question 2. Basically, I have another COM object that I'm trying to work with, but when I run my application, I get an exception to the effect of "COM object with CLSID {X} not found" ... all the info that needs to be in the registry about that object is there, because my Visual Basic 6 code written for that same object works just fine. Here's what I do:

1. Get .NET interface to COM object with tlbimp.
2. Add COM reference to project.
3. Write some cool code.
4. Compile.
5. Put executable and .NET COM object wrapper on test machine.
6. Run regasm.
7. Run code.
8. Get exception, bang head against wall.

I think it's odd that this procedure works just fine for one COM object but apparently isn't good enough for another COM object. Am I missing something here? (Regsvr32.exe will not work on the COM object.

One last thing I want to point out -- both of these COM objects were written by different companies, so I can not modify them on whim

Thanks!

 

[Nicholas Paldino [.NET/C# MVP]]

Uty,

I'm not quite sure about your first question. From what I can tell, you
should just cast the return type to the Class type that you want. However,
I would recommend using the interface instead. When you create a COM
component in VB, you have a class implementation, but all of it's details
are private. In reality, VB exposes an interface that is associated with
the class type. When you pass back an instance of your type, you really are
passing an interface, a detail that VB hides for you. This is why you have
a number of interfaces with an underscore in front of them, these are the
interfaces that are actually generated.

As for your second question, you are not registering the original COM
component. You do not need to use regasm on the .NET COM wrapper. Rather,
you need to call regsvc32 (or the executable itself, if it is out of
process) to register the component. The wrapper needs no registering.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

As the subject suggests, I have two questions about using COM objects in

C#. I'm using two different objects, each of which is giving me a problem.

The first object ... we'll call it AppXControl. Here's some Visual Basic 6

code I've written which gets the code connected to the COM object.

Private WithEvents xControl As AppXControl.Control
Private xConnector As New AppXControl.Connector

** This line of code is in FormMain_Load()
Set xControl = xConnector.xMonitor

Basically, you instantiate two classes defined in the COM object. The

first is a controller -- this is the actual object that catches triggered
events and so on. The second is a connector. You instantiate it, and use
xConnector.xMonitor to get an xControl object for use in doing COM with
ApplicationX.

Here's the corresponding C# code:

public class Form1 : System.Windows.Forms.Form
{
private AppXControl.ControlClass xControl;
private AppXControl.ConnectorClass xConnector = new AppXControl.ConnectorClass();

...

public Form1()
{
InitializeComponent();
xControl = xConnector.xMonitor;
}

...
}


Here's the problem. In the Form1 Constructor, xConnector.xMonitor is

returning an object of type AppXControl ... but what I really need here is
an object of type AppXControlClass. The COM object itself has no knowledge
of this AppXControlClass, it is created by C# when the object is ported to
the .NET framework with tlbimp. Is there any way I can get the AppXControl
object instead of AppXControlClass without asking the COM object's vendor to
rewrite their code? (Which I doubt they'd do anyway.)

Now on to question 2. Basically, I have another COM object that I'm trying

to work with, but when I run my application, I get an exception to the
effect of "COM object with CLSID {X} not found" ... all the info that needs
to be in the registry about that object is there, because my Visual Basic 6
code written for that same object works just fine. Here's what I do:

1. Get .NET interface to COM object with tlbimp.
2. Add COM reference to project.
3. Write some cool code.
4. Compile.
5. Put executable and .NET COM object wrapper on test machine.
6. Run regasm.
7. Run code.
8. Get exception, bang head against wall.

I think it's odd that this procedure works just fine for one COM object

but apparently isn't good enough for another COM object. Am I missing
something here? (Regsvr32.exe will not work on the COM object.)

One last thing I want to point out -- both of these COM objects were

written by different companies, so I can not modify them on whim.