.NET Assemblies vs. COM DLL

[Greg]

A COM object is in a thread as a running binary that is available to be used
by it's clients.

..NET Assemblies refer to DLLs that have MSIL not binary code. Do .NET obects
run in their own threads? Is it simply a matter of copying the object's MSIL
code so that the .NET object binary is not accessed in a thread the way COM
objects are?

--
Greg McPherran
www.McPherran.com

[Mattias Sjögren]

A COM object is in a thread
What exactly do you mean by that?

Do .NET obects run in their own threads?
If you mean that there is one thread per object, then no.

Is it simply a matter of copying the object's MSIL
code so that the .NET object binary is not accessed in a thread the way COM
objects are?

Not sure what you mean by this either.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Greg]

Hello Mattias,

I seek an understanding of how objects are used at runtime in .NET as
compared to COM.

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
--
Greg McPherran
www.McPherran.com
"Mattias Sjögren" wrote:

A COM object is in a thread

What exactly do you mean by that?

Do .NET obects run in their own threads?

If you mean that there is one thread per object, then no.

Is it simply a matter of copying the object's MSIL
code so that the .NET object binary is not accessed in a thread the way COM
objects are?

Not sure what you mean by this either.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Mattias Sjögren]

the COM object is loaded into a thread of the
application process at runtime (if I'm not mistaken).
I wouldn't say that the object is loaded "into" a thread.

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
Yes

Also, from what I understand, .NET objects are in the same thread as the client
unike a COM object which uses a separate thread.

No, COM objects don't automatically run on a separate thread. COM
objects and .NET objects work more or less the same in this regard.
The biggest difference is that in COM you may have to worry about
apartments, but the apartment concept doesn't exist in a pure .NET
world.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Richard Grimes [MVP]]

Greg wrote:

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).
The point of registration is that it is a mechanism to associate the
unique name of the COM class (the CLSID) with the server that will be
used to create it. In other words it's a bit like a replacement for
LoadLibrary/GetProcAddress, except you don't have to give the name of
the server when instantiating a COM object, you just give the name of
the class.

Threading is handled through apartments. Most objects will specify the
type of apartment that they require because this also describes their
behaviour to being accessed by multiple threads. Only code in an
apartment can call COM objects so that means that all threads that
access (or host) COM object must be in apartments.

An STA object has no thread synchronization in its code and therefore it
can only be accessed by the same thread, if any other thread accesses
the object then the method call will be serialised as a Windows message
and put in the message queue attached to the STA thread. Periodically
the message queue is pumped for messages, and so the STA thread will get
the message and run the method. If an STA object creates another STA
object then the two will run in the same apartment (and their code will
only be called by the same STA thread).

An MTA object has thread synchronization in its code (or has code that
doesn't care about threads). The process will always have a thread pool
of threads that will run in the MTA. If an MTA thread creates an MTA
object and calls the object then methods will be run on that thread. If
an STA object creates an MTA object and calls it then a thread pool
thread (MTA thread) is used to make the call, so that means that there
is a transition from the STA thread to the MTA thread, and this is
called marshalling. Similarly if an MTA object creates and calls an STA
object then a new STA thread is created and the STA object will be
called on that thread and the inter-apartment (ie inter-thread) calls
will involve marshalling.

There are some COM objects that don't care what apartment they run in
(Both apartment type) and so these are created in the apartment of their
creators (STA or MTA). Note that STA objects are bound to the single
thread - they will always be called on the same thread - however an STA
thread can have more than one object. An MTA object can be called on any
of the threads in the MTA, so it is not bound to a particular thread.
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?
Unless you use ngen (the native image generator), the code is just in
time compiled on a method-by method basis, that is just before a method
is called for the first time JIT compilation occurs. The code is then
cached and used for subsequent calls to this method in this instance of
the process. JIT compilation has a security aspect too - if your code
uses link demands and it is ngen'ed, ngen will be repeated if the
security policy is changed.
Also, from what I understand, .NET objects are in
the same thread as the client unike a COM object which uses a
separate thread.
They don't have to be <g> If you call an object's methods asynchronously
then a thread pool thread will be used.

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

COM components are instantiated through a request to the COM runtime,
which is a little like an object broker - the COM runtime uses the CLSID
you provide to locate the server, it then loads the server and accesses
the class factory, and finally it requests an instance of the class with
the CLSID. This is dynamic linking and binding - as I said earlier, it
is a 'safe' equivalent of LoadLibraryEx and then calling GetProcAddress.

With .NET the linking and binding is static - the compiler *requires*
the metadata of the object when it compiles your code and a static
'link' is put in the assembly which effectively says 'create an instance
of this specific class in this specific assembly'.

Richard
--
Fusion Tutorial: http://www.grimes.demon.co.uk/workshops/fusionWS.htm
Security Tutorial:
http://www.grimes.demon.co.uk/workshops/securityWS.htm

[Ken Halter]

"Richard Grimes [MVP]" <ri******@mvps.org> wrote in message
news:Oq**************@TK2MSFTNGP10.phx.gbl...

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?

Unless you use ngen (the native image generator), the code is just in time
compiled on a method-by method basis, that is just before a method is
called for the first time JIT compilation occurs. The code is then cached
and used for subsequent calls to this method in this instance of the
process. JIT compilation has a security aspect too - if your code uses
link demands and it is ngen'ed, ngen will be repeated if the security
policy is changed.

Why does all of this JIT / ngen stuff sound like "Free code for all" Plus
just begs for statements like.... "12ghz PC required"?

fwiw, we have an old VB3 app that runs fine, no matter what PC hardware you
throw at it... and plennnnty of VB6 generated binaries that do a great job
of hiding the source and still run on any PC we've ever had... from 286's to
3+ghz pentiums. No JIT, No ngen, No obfuscator, No problem.

--
Ken Halter - MS-MVP-VB (visiting from VB6 world) - http://www.vbsight.com
Please keep all discussions in the groups..