STA/MTA is hideous. Yes, I know the wool has been pulled over my eyes a bit on how .NET manages all this but to tell you the truth... I really don't care. Go try to write a COM object sometime that MUST be an STA (VB and ASP require it) but ALSO must be multithreaded AND be able to process Windows messages. Trust me, it's not an easy feat. You have to get down deep into the bowels of marshalling and creating your own message pumps, dealing with things you don't even wanna know about and it's a COMMON problem. If you live in a world of pure MFC and C++ it doesn't make a huge difference.... but nowadays we're all saddled with supporting lots of VB users. Excuse my ignorance here, but what particular technique could you use to implement .NET component that simultaneously supports: -- STA, MTA, Windows Messages... What would be that? From what I understand appartment threadind is global in .NET. What exactly do you mean? At least COM supports Free Thread marshalling, so Free Threaded COM component doesn't care. So, what is it in .NET that will make the same component to work purfectly well hosted in STA, MTA and as a Control??? Alot of my experience in integrating the ATL COM world with VB6 and ASP forced me to learn a LOT new things and types. It was a huge hassle when needing to be able to write a COM component that could work in a MFC application, a VB6 application, AND be useable in both VBScript and Javascript for use in ASP. Here I also confused a lot. So, your point is that in .NET you can write components easily accesible from MFC, VB6, VBScript and Javascript? If so, from what I know those one are Interop COM components. Or maybe you are trying to say that you just don't have necessaty now to support MFC, VB6, VBScript and Javascript? If so, that just means that your containers changed: but is this good by itself? So, you are now limited by supporting less poossible clients... "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me