What replace COM object in .NET?

[gulu man]

Hi,
What is the substitute for COM objects in .NET?
How can I create something similar to com in .net?


Is it still possible?


Thank you

 

[WJ]

Hi,
What is the substitute for COM objects in .NET?

..Net managed Classes

How can I create something similar to com in .net?

Click here to learn more:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/manunmancode.asp

Is it still possible?

Yes, just tells your .Net assembly it is OK to call unmanaged codes.

John

 

[Scott M.]

It's not really what replaces COM in .NET. .NET is a replacement for COM.
When you make a class in .NET, you have just made a .NET object.

 

[Peter Rilling]

You can also make COM objects in .NET.

It's not really what replaces COM in .NET. .NET is a replacement for COM.
When you make a class in .NET, you have just made a .NET object.

 

[Scott M.]

Well no, not really. This discussion/debate has raged on for some time now,
but I fall down on the side of: You can not make COM objects in .NET. You
can create a wrapper class (COM Callable Wrapper) that wraps the actual .NET
component up and provides COM based interfaces to the .NET object, but the
object still runs within the context of the CLR.

Similarly, you can't make .NET objects from, say VB 6.0. What you can do is
create another type of wrapper class (a Runtime Callable Wrapper or RCW),
that exposes the COM object to the CLR with .NET interfaces. The COM object
still runs within the context of its own runtime (in VB 6.0's case,
MSVBVM60.dll).

 

[Scott M.]

Just to follow up on that:

Objects created in .NET, run within the context of the .NET Framework and
the CLR (Common Language Runtime). These objects are said to be "Managed
Assemblies" because the CLR is responsible for their memory
allocation/de-allocation, the exception throwing and handling of the object,
etc. The CLR is managing the object.

COM objects are said to be "Unmanaged Assemblies" because they are not
managed by the CLR under any circumstances. Their memory
allocation/de-allocation and the handling of throwing and catching
exceptions as well as the normal processing of their code is NOT managed by
the CLR.

Regardless of whether you use a COM object in .NET or a .NET object in COM,
the object will remain managed or unmanaged depending on what architecture
it was created in.

 

[Peter Rilling]

Interesting perspective. What is a COM object then? What is the difference
between creating COM object in VB6 or C++ and creating a wrapper in .NET?
The COM specification does not discuss implementation but rather then
interface for accessing the methods of some code library. It just accesses
the actual binary code through the use of fucntion tables, right?

 

[Scott M.]

This is why I said this topic has been discussed/debated for some time.

Because COM objects come with so much of their own "baggage" and rules and
..NET components do not come with that same "baggage" and rules and because
COM objects use a different runtime to process their code than .NET objects
do, I would say that a COM object is an object that *natively* exposes the
interfaces specified by the COM architecture. .NET objects do not NATIVELY
expose these interfaces.

Even when you create InterOp wrappers (either a CCW or an RCW), the *actual*
assembly does not change. All you've done is create a new assembly that
wraps the .NET assembly but places COM interfaces around the .NET object(s).
So, the .NET object(s) do not change in any way.

 

[Vipul Taneja]

Pretty interesting. I think following scenario will explain that nothing in
..NET can replace COM.

I needed to write a outlook add-in which will internally invoke few
webservices. I was preferring to write it as .NET component (as it is
webservices client) but it must implement COM interface IDTExtensibility2.

Now as I understand .NET component can not implement COM interface. So I'll
have to use something like VBA, VB or VC++/ATL, which might invoke .NET
compoenent to access WebServices. Eventually, to keep it simple, I decided
to use VC++/ATL com which itself will invoke WebServices.

Do you agree with this decision?

 

[Scott M.]

No, I don't think you've quite got it. .NET components CAN, in fact, expose
themselves to COM via COM Callable Wrappers (CCW's). In VS .NET, go to the
project's properties and look at the "Build" category of choices. If you
check off "Register for COM InterOp", then when you compile the project, VS
..NET will generate a Type Library file (.tlb) for your .NET component. This
..tlb file is what you will need to make a project reference to from Outlook.

What we've been discussing here is whether the process I've just described
means that .NET can create COM objects. I say, "no", because that .tlb file
is nothing but a wrapper for the native .NET object that will still run
within the context of the CLR (oh yeah, you will need to have your target
machine loaded with the .NET Framework so the .NET component can run).

So, although .NET components can be *exposed* to COM via wrappers, they
remain .NET components because of where their actual code is processed (the
CLR and the .NET Framework).