AOP and .NET: Is Contexts an obsolete concept?

Question

Recently I've started learning about Contexts in .NET (context-bound, context-agile, message sinks, etc.). Several alarm bells started ringing:

1. All context-bound classes are derived from ContextBoundObject, which in turn is derieved from MarshalByRefObject. MarshalByRefObject is a part of the .NET Remoting architecture. The .NET Remoting architecture is considered obsolete.
2. Most .NET-related books pay little to no attention to the concept of Contexts.
3. MSDN barely provides any information on Contexts: classes are explained, but sattelite-articles (such as "How To"s, "Overview"s, "Tutorials" etc.) are not provided.
4. Most articles and forums threads discussing Contexts are a few years old.
5. Aside from the Synchronization context, it seems that the .NET framework makes little-to-no use of the Contexts architecture.

Thus, my question is: Is the concept of Contexts in .NET obsolete and should be avoided in new developments? If it is obsolete, what alternatives are recommended?

Answer 1

Yes, avoid MarshalByRefObject and ContextBoundObject for AOP.

I rolled a custom AOP solution about four years ago using the context-bound MarshalByRefObject method. I knew at the time I was going down a rabbit hole but did it anyway because many of the AOP frameworks for .NET were still very young.

The fact that .NET supports AOP with MarshalByRefObject is a happy accident. MBO was never intended for that purpose, and using MBO for AOP is a hijacking of the original intent of .NET remoting and MBO.

None of this means that .NET can't support AOP, just that it should be done in a less "hacky" way, using a framework that supports AOP, like Spring.NET, PostSharp, and others.

Here is a good, if a little dated, article on AOP frameworks for .NET.

Answer 2

I stand to be corrected but if you are restricted to using "Vendor" (re:Microsoft) code, I believe there is a degree of AoP in Unity and/or the MS Enterprise Library Policy block.