Re: [STAThread]
- From: "Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx>
- Date: Wed, 12 Apr 2006 01:11:44 +0200
"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message
news:MPG.1ea602fc4da98b5f98d08b@xxxxxxxxxxxxxxxxxxxxxxx
| Willy Denoyette [MVP] <willy.denoyette@xxxxxxxxxx> wrote:
| > | Nah - I hardly know anything about COM. I've seen various things about
| > | COM marshalling "just working" that never seemed to "just work" when I
| > | tried it. My knowledge is very flaky in this area. I want it to stay
| > | that way in some senses - I hope to have very little to so with it!
| >
| > Well, you can hardly stay out of it, remember .NET on Windows is COM3
:-),
| > take away COM and look what's left.
|
| Quite a lot, IMO. Put it this way - I doubt that Mono on Linux uses
| COM, and it still manages to be useful. Java doesn't use COM (at least
| not on non-Windows platforms) and manages to achieve many of the same
| things as .NET. I don't see why COM is a necessary part of applications
| which don't appear to naturally require it.
|
True, but that's because Linux doesn't have COM. That means you don't need
to interop with existing COM servers (like the Office product suite,
Exchange server, a zillion of VB6 applications....). Believe me, without
COM, .NET would have died before it was even born, for the same reason why
Java failed on the Windows client. Note also that Windows isn't Unix or
Linux, most existing applications on windows are COM based (directly or
under the covers). Services like Exchange, SQL Server and many more expsose
their functionality to the external world through COM. Internally, they use
COM as a glue in order to build complex systems using an higly modular
design (look at SQL server and count the number of COM dll's included in bin
and bi.
To get an idea about the number of COM interfaces available in a system,
watch your registry and count the number of COM classes registered, you
might be suprised.
Nor does it have to interop with things like Active Directory,ADO, COM+
services, CDO, OLEDB, OleTx, MSMG, DirectX and WMI to name a few, that's why
there are no System.DirectoryServices, System.EnterpriseServices,
System.Messaging, System.Data, System.Transactions, System.Drawing and
System.Management namespaces available in mono.
And don't get me started on the profiler, debugger and hosting services as
now available in V2, the hosting interfaces,just like the profiler and
debugger interfaces (COM) are needed to ease the interoperation between
unmanaged code and managed code. The unmanaged (again COM) hosting interface
is used by SQL Server 2005, and all serious debuggers and profilers are
written in unmanaged C/C++.
| > Also, don't believe that COM is going
| > away, it's just moving down from the user level to the system level,
Vista
| > has a lot more COM components added than there are .NET components.
Actually
| > Vista can run without .NET, but it can't without COM.
|
| Fine, I can live with that.
|
| > Note that I'm not talking about technologies built on top of COM (like
| > ActiveX, OLE etc), I'm talking about the low level COM binary interface
| > standard, which makes it possible for software components (whatever
| > language) to interoperate seamlessly using a well defined standard
| > interface.
| > Once you understand the COM interface definitions (the object model) and
| > it's rules, you'll better understand why/how things are working (or
| > fail).
|
| Hmm... unfortunately, in my limited experience things don't quite work
| as they're meant to. For instance, the way you expressed the use of COM
| in a previous message suggested that if I'm using a COM wrapper that
| requires an STA, it's more efficient to specify STAThread but that
| things should still work without, via marshalling. Well, thinking of
| the one time I've definitely had to use COM explicitly in C#, things
| didn't work at all without STAThread. (I can't remember the exact error
| message, unfortunately.) It could very well be that this was a badly
| written COM library, but my impression from messages I've read over the
| years is that there are more badly written bits of COM than well
| written ones...
|
The major problem with .NET is the fact that users start to run multiple
thread to create all kind of objects, without respecting some basic rules.
Two important rules that seems to be forgotten quite often, are:
- Windows UI elements have thread affinity, so don't touch them from another
thread than the creator's thread, and
- 'Apartment' threaded COM objects have STA thread affinity, and while COM
takes care of this, it's far better to arrange that your objects run on the
creator's STA thread, which is preferably the UI thread. If you don't take
care of this, you'll incur marshaling overhead, worse, if your objects
marshals to the COM default thread, make sure it's a pumping thread (like
the UI thread), or you will block the finalizer thread.
Note that you might have some issues with 'apartment' threaded objects in a
multi-threaded application, but once you follow some simple rules, they are
quite simple to use. Note also that most COM classes are 'both' threaded, so
they can live in an STA and an MTA. Some quite sophisticated COM objects are
thread neutral (just like CLR objects), and they don't need an apartment to
live in, but they are quite complex to author (correctly).
Honestly, take some time to learn the basics of COM, I'm sure you will like
it.
Willy.
.
- Follow-Ups:
- Re: [STAThread]
- From: Jon Skeet [C# MVP]
- Re: [STAThread]
- References:
- Re: [STAThread]
- From: Willy Denoyette [MVP]
- Re: [STAThread]
- From: Michael Nemtsev
- Re: [STAThread]
- From: Jon Skeet [C# MVP]
- Re: [STAThread]
- From: Willy Denoyette [MVP]
- Re: [STAThread]
- From: Jon Skeet [C# MVP]
- Re: [STAThread]
- Prev by Date: Re: Winforms Picturebox control
- Next by Date: Re: C# Remoting ???
- Previous by thread: Re: [STAThread]
- Next by thread: Re: [STAThread]
- Index(es):
Relevant Pages
|
