Deciding Whether an Object Is Interceptable

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
The latest Enterprise Library information can be found at the Enterprise Library site.

The default interception mechanism in the Policy Injection Application Block takes advantage of .NET Framework remoting proxy instances. The application block can create an instance of a suitable proxy class that appears to client code as though it is the "real" target object. The client works with the proxy in exactly the same way as it would with the real target object. Code in the application block passes a request from the proxy through the configured handlers before it reaches the target object, and then it passes the request back through these handlers in the reverse direction after it executes the target object method.

Therefore, unless you change the default interception method, the objects you create or wrap using the Policy Injection Application Block must meet either of the following two conditions:

• Derive from the class MarshalByRefObject. The Policy Injection Application Block can intercept and add handlers to public methods and properties of classes that inherit from the abstract base class MarshalByRefObject, which the .NET Framework uses for objects that exchange messages across domain boundaries using .NET Framework remoting.
• Implement a known interface. The Policy Injection Application Block can intercept and add handlers to public methods and properties defined in an interface that classes implement. Any members of the target object not defined in the interface will not be accessible through the proxy that the application block generates.