Calling COM Objects

COM and .Net

COM libraries can be referenced as easily as managed libraries. On the Add Reference page there is a tab labelled COM which lists COM component libraries. When the reference is added, a managed namespace with managed types is automatically created to wrap the COM library. You can then use the types as normal.

Good luck :)
 
Re: COM and .Net

COM libraries can be referenced as easily as managed libraries. On the Add Reference page there is a tab labelled COM which lists COM component libraries. When the reference is added, a managed namespace with managed types is automatically created to wrap the COM library. You can then use the types as normal.

Good luck :)

Thx MrPaul. I got that.

Heres another thing I need to discuss. Most of the samples I got when doing COM development is in VB with the CreateObject function. Anybody knows the counterpart for that function in C#?
 
CreateObject and late binding

You would only really need to use CreateObject in late binding scenarios. C# does not natively support late binding as VB does (and arguably rightly so), but it can be done.

However, to use an object in any meaningful way requires you to know what that object is, so there is very rarely a need for this late binding behaviour. The implication of this is that the majority of the time you see CreateObject being used, it should not be - a sign of lazy programming.

The correct approach in .Net is therefore to add the COM component as a reference and use the new operator as usual.

If you do need late binding, then you can use Type.GetTypeFromProgID followed by Activator.CreateInstance, and then InvokeMember to invoke the members. Seems like a lot of hassle unless you really need this behaviour.

Good luck :cool:
 
Re: CreateObject and late binding

Okay. I got the last part about Type.GetTypeFromProgID and Activator.CreateInstance. But do you really need to use the InvokeMember method? Btw thats the Type.InvokeMember method right?

Currently I believe I do need late binding. Ive done the usual steps. Adding to the reference and using it like any typical object. It doesnt seem to work.

About late binding. Does it affect performance?
 
Re: CreateObject and late binding

Could you post a sample of the code you are using that isnt working? Also when you say doesnt seem to work is it failing in any particular way?

Late binding will affect performance (just how much really depends on several factors) as you are doing a lot of work at runtime (id lookups, interface lookups, method lookups etc.) that can be done by the compiler if you are early binding.
 
Re: CreateObject and late binding

Im trying to use a third party COM objects to convert documents to HTML format. I need to call the "Convert" method of the main object.

Heres the code to call the convert method.

[csharp]
int result = mglObj.Convert(infilename, outfilename, out errMsg);
[/csharp]

Basically I need to create mglObj.

This one doesnt works.

[csharp]
Type type = Type.GetTypeFromProgID("MagellanSolo.Loader");
Loader mglLdr = (Loader) Activator.CreateInstance(type);

MagellanSolo mglObj = (MagellanSolo)mglLdr.MagellanSolo;
[/csharp]

This one works.

[csharp]
Loader mglLdr = (Loader)Server.CreateObject("MagellanSolo.Loader");
MagellanSolo mglObj = (MagellanSolo)mglLdr.MagellanSolo;
[/csharp]

Maybe Im missing something. I really dont know. I think Ill look into it again while I still have the time.
 
Re: CreateObject and late binding

If you add a reference to the dll itself could you not just do something like
C#:
Loader mglLdr = new MagellanSolo.Loader;
MagellanSolo mglObj = (MagellanSolo)mglLdr.MagellanSolo;
 
CreateInstance vs new

The reason your C# sample doesnt work is this: Clearly youve referenced the COM DLL, as youre able to declare variables of type Loader and MagellanSolo. In that case, the correct way to instantiate the loader object would be to use new as PlausiblyDamp mentioned. Using Activator.CreateInstance creates an instance of the COM object but it is probably being returned as a generic wrapper type - not an instance of the managed Loader class (which was generated when you referenced the DLL). The generic wrapper instance cannot be cast to type Loader. To fix the problem, just use new instead of Activator.CreateInstance.

As for why the essentially equivalent VB sample works is that clearly VB works in mysterious ways. :rolleyes:

Good luck :)
 
Re: CreateObject and late binding

From what I learn, it is true that when we reference a DLL or EXE file, we can directly use the object using the "new" keyword. Thats the first basic step that I tried. I didnt even consider using the Activator.

I look in the manual for the COM objects. It does specifies specific steps needed to be done when using the COM in a web application environment. Currently I believe this is the main reason why the usual way to create a COM object doesnt work.

So I followed the steps. I use the sample VB code to create my C# code. Success.

I dont really now the difference process perform when using the "new" keyword, using the Activator object, or using the CreateObject method. I really like to know.

The performance of my application when executing the COM object is considered poor. Maybe the late binding really took a huge effect on the performance.

Either way Ill look into it. I need to optimize my code anyway. :D

Ill post additional information if I have any.

Thank you all for the help.
 
Re: CreateObject and late binding

Still not entirely sure what the actual error youre having is; is it failing to create the objects? The objects failing to execute correctly? Some other problem?
 
Re: CreateObject and late binding

At first Im guessing it has something to do with the creation of the object. Thats why I started this thread asking the appropriate way to create a COM object. Currently I have my own doubt. Maybe the actual problem is not in failing to create the object. Maybe its simply a matter of failing to execute properly. I still have to give it a try though. Ill post any relevant information if I have one.

Thanks.
 
Re: CreateObject and late binding

The code I posted earlier is definately all you need to create an instance of a COM object (assuming it is referenced by your project), this will also allow you to use early binding which should be better for performance.

If you step through the code in a debugger are you getting valid instances of the objects created? If so then you shouldnt need to use either Activator.CreateInstance or Server.CreateObject to instantiate the objects.
 
Re: CreateObject and late binding

Hi guys.

I can finally confirmed that the early binding works perfectly. I tested my code again using the typical early binding method to create my COM object and voila. I works just like when I use any late binding method.

I apologize for the confusion when discussing this issue. I thank you all for your replies.

I guess theres nothing wrong with using early binding. I guess the error comes from using the COM object incorrectly. I tested my code using the early binding over and over and no error have been found.

I hope Ive clear the confusion here. Thank you again.
 
Back
Top