Another Chris Brumme volume

Apartments and Pumping in the CLR.  I'm pretty sure that the threading models that COM supports are one of it's least-understood aspects, and one of my favourite aspects of .NET is that it mostly makes it go away (except when you have to interop).  It's kind of funny, though, that VS.NET inserts a little nod to COM into every .NET application it's wizards generate by including the  [STAThread] attribute on the main entry point.


On one hand, it's cool that there's so much going on behind the scenes to shield mere mortal developers from all this complexity, but on the other hand, I think it's this complexity that makes things hard to develop and debug in the first place. 


For example, if they'd kept the threading model as something that could easily fit into the head of an average developer (like with a simple rule like 'you can only call a COM object on the thread that created it') would it have been better in the long run?  I think the scenarios where you need to share COM objects between threads are relatively uncommon and can be easily designed around, by having your own thread that's responsible for calls into the object, and setting up a queue inside your application.. At least that way all the guts are transparent (they're in your code where you can debug them).


Having a framework do a lot for me is cool - as long as I know what the framework is doing.  When I say “Image.FromFile(fileName)' I know the framework is doing a lot for me, but I have a pretty good idea what it is (figuring out what type of file it is, calling code that knows how to decompress a JPEG image, etc).  Ask yourself if you really know what's happening when you pass a structure to a COM object that's running in another process.


A better solution, if it really does have to be so complex (and it probably does - the complexity is there to create the illusion of simplicity for the average developer, who probably doesn't really care what happens to his structure, as long as it arrives) is to give out the source to the complex bits so that when it doesn't do what we expect, we have some recourse.


MFC was a complex beast in it's day, and I know a lot of developers had troubles with things like the way it would route messages around an application or figuring out how to get the Document/View stuff really working well - but you always had a way to figure out what was going on, because you had the source for it.


Developers could really benefit from parts of the .NET framework source being made available, to give developers some hope when things don't work the way we expect. Not for the parts that are fairly obvious (like System.Windows.Forms) but for places like the System.Runtime.InteropServices namespace (and maybe WinFX, if it's to be something like MFC) where some visibility would really help.