I recently commented on one of Eric Gunnerson's posts, suggesting the use of CLR contexts. Damien Morton, to whom my comment was directed, has since correctly pointed out that it was a very off-hand reference and did not give much of a clue as to how they might help. Rather than reply just to him, I thought I'd give a brief overview of contexts. For more details, check out Don & Chris's "Essential .NET", where I gleaned this info. Unfortunately I do not have a copy of that excellent tome to hand at the moment, so there are definitely some omissions in what follows, and quite likely some errors too.

Basically, if an object derives from ContextBoundObject (itself derived from MarshalByRef object), then any of its attributes that derive from ContextAttribute start to come into play. On creation, these attributes determine whether the new object can "live" in the current context, or whether a new one should be created. This involvement in object creation was where I thought contexts might come in useful for Damien's "attribute schema" requirement.

Additionally, and very usefully, method calls between contexts pass through various stages of "plumbing", which allows the developer to hook into the process. This is particularly useful in AOP scenarios. It is also used by .NET remoting, so Ingo Rammer's book also covers this.

For those with a COM/DCOM/MTS/COM+ background, this is reminiscent of the various schemes that these technologies used internally, but in .NET is has been generalized so the developer can get in on the action as well.

There is obviously much more to contexts than this, but hopefully this brief overview is enough to pique people's interest, and give them some idea whether contexts could be useful in their applications.