.NET Object vs. COM Object

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

What are the compile time and runtime differences between a .NET object?

For example, with COM, an object is compiled and delivered as a native
binary. It must be registered on the target machine. Then when an app is run
and it uses the COM object, the COM object is loaded into a thread of the
application process at runtime (if I'm not mistaken).

For a .NET object (call it object_dotnet) that is in a DLL, is the object
itself loaded and JIT'ed when a client app uses it or is it built and JIT'ed
with the client app at compile time when the main app exe is created? Also,
from what I understand, .NET objects are in the same thread as the client
unike a COM object which uses a separate thread.

Any insight into the compile and run time differences between a COM and a
..NET appreciated.

Thank You
 
Compile time differences:

..Net at compile time compiles into MSIL (Microsoft Intemediate
Language) which is a assembly type intermediate language that all .net
modules (assemblies and executables) target. You can generate native
images of .net objects by running ngen.exe on compiled .net assemblies
and then the runtime will use the native images for execution

Runtime differences:
At runtime, .net assemblies are handled by the CLR (Common Language
Runtime) which includes a JIT compiler. When .net executables run they
are loaded by the CLR and the JIT compiler converts the MSIL in the exe
into native machine instructions. This does not mean that all
assemblies are JIT compiled at once, but rather JIT compiled as
assemblies and the functions defined in those assemblies are used.

The major difference between COM and .Net is that COM required
registration of all the interfaces it supports and exports so that
clients of the COM objects can use those interfaces to get access to
its members. In the .Net world no registration is required since .net
assemblies contain full metadata information of the types, members and
methods it contains.

..net object also use the STA threaded model rather than the MTA
threaded model that COM uses.

Hope this helps...
-NuTcAsE
 
1. It would seem that a key difference between COM and .NET is that COM
objects are built and reused by apps as binaries whereas .NET objects can be
reused by apps in MSIL form. ?

2. Does .NET support runtime features such as opening a spreadsheet using a
spreadsheet control within a word processer? How would this be done? Would
the spreadsheet control be JIT'ed the first time it's instantiated in the
word processor? (again, referring to runtime, not build time).

Thank You
 
NuTcAsE said:
.net object also use the STA threaded model rather than the MTA
threaded model that COM uses.
Click to expand...

Not true.

By default .NET uses MTA, but for UI elements if you use COM you *have*
to use STA. This is why .NET applications have [STAThread] on the Main
method - it tells .NET that if code uses COM and the thread is not in an
apartment then .NET should make the thread join an STA. Note that a
Control object is a COM object because the underlying code uses OLE to
perform drag and drop, so therefore your GUI application *must* have
[STAThread] on the Main method (strictly speaking the entry point of the
GUI thread). If you write a console or service app, or write enterprise
services components, then you can use MTA if you chose to (and you
should).

Both COM and .NET (and MTS and COM+) give the developer the option of
what apartments are used. However, VB6 objects are always STA because -
well, as far as COM is concerned - VB6 is braindead. C++ COM objects can
be written for *any* apartment type.

Richard
 
Greg said:
1. It would seem that a key difference between COM and .NET is that
COM objects are built and reused by apps as binaries whereas .NET
objects can be reused by apps in MSIL form. ?
Click to expand...

The key difference is that COM classes have to be activated through COM,
which means that they must be registered with the system.

Another key difference is that location transparency support is
automatic - a COM object (in a DLL) can be activated in process, in
another process on the same machine (dllhost) or in another process on
another machine via DCOM. All you need to do is make a change in the
registry. A COM object can also be run under COM+, again, all is needed
is to install the server in COM+. With .NET to get location transparency
you have to specifically think about this when you are developing it
because the class *must* be derived from MarshalByRefObject. Similarly
if you want the option to run the object under COM+ sometime in the
future then you must specifically write the class to enable this, you
need to derive the class from ServicedComponent and you have to add some
attributes to the assembly. Since you can only derive from one class in
..NET these requirements restrict your development.

..NET classes are not registered with the system. If a class is in a
private assembly then the private assembly simply has to be in the app
folder (or in a subfolder).
2. Does .NET support runtime features such as opening a spreadsheet
using a spreadsheet control within a word processer? How would this
Click to expand...

In-place activation is an OLE (ie COM based) technology. .NET makes no
attempt to replicate this. Similarly for object linking and embedding
and for drag and drop - these are all COM technologies. There is no .NET
equivalent. Thus for the forseeable future, COM will not die.
be done? Would the spreadsheet control be JIT'ed the first time it's
instantiated in the word processor? (again, referring to runtime, not
build time).
Click to expand...

It is possible for a .NET control to be hosted inside an ActiveX
container (don't ya just love all of these buzzwords?). In VS2005 MFC
has a class that allows this. Remember that Control is a COM object, so
most of the support has been in Windows Forms for activation in an
ActiveX container right from 1.0. When the .NET control is activated and
a method is called, the first call (and only the first call for this
process) to each method will cause the method to be JIT compiled.

Richard
 
Back
Top