Effective Policy Viewer for the Policy Injection Application Block

I hope you're enjoying the new release of Enterprise Library! One of the more interesting inclusions in this release is the new Policy Injection Application Block. The goal of the PIAB is to make it easier to separate cross-cutting concerns from business logic, using declarative policies. A policy consists of a set of matching rules, which indicate which objects and methods the policy applies to, and a chain of handlers, which are objects that execute before and/or after a method is called to accomplish interesting stuff. The PIAB ships with 6 handler types that provide implementations for logging, validation, exception handling, authorization, caching and performance counters.

Using the PIAB intelligently in your application should allow you to write simpler, more maintainable code. However a few people have already pointed out that this separation of business logic from cross-cutting concerns has the potential to cause confusion, since it won't be possible to understand the complete behavior of the application by looking only at the code. While this problem can be mitigated by applying handlers directly using handler attributes or indirectly via the TagAttribute, I do agree that this style of development does carry a different set of risks to more traditional development styles.

To help take the mystery out of which policies will apply to which objects and methods, I put together a simple tool called the Effective Policy Viewer. This tool is not included in the Enterprise Library 3.0 installer; instead I've uploaded it directly to the EntLib CodePlex site, so we can more easily update it over time. Here's the tool looks like:

The tool lets you load an assembly, and optionally a configuration file (if you don't select a configuration file it will only look for handlers applied using attributes). The left-hand tree view control will show all of the namespaces, classes and members in the assembly. If a class appears greyed-out, it means that none of the members have policies applied to them. If the class is black, you can expand it to see which members have policies applied to them. Selecting a member will show the list of policies and handlers in the right-hand tree view control. The order that the handlers are listed in the control reflects the order that they will execute at runtime. Keep in mind, however, that policies will only run when objects are created or wrapped using the PolicyInjection class, but this tool can't verify that you're doing this.

Please let us know if you have any feedback or problems with this tool. This was built in my spare time so it hasn't gone through any real review or tests, but if there are problems then it shouldn't take long to update it. If anyone feels like "supercharging" the tool and sharing your changes, please go right ahead!

Comments (9)
  1. Daniel Melo says:

    Hi Tom,

    Is it confirmed that handlers applied by attributes can’t have the order of execution garanteed?

  2. Hi Daniel –

    Unfortunately this is the case – the Reflection classes that return attributes do not guarantee the order. The documentation doesn’t really say anything about the topic, but I did some experimentation and found that the attributes are returned in the same order that they are defined in the MSIL (which can be viewed using ildasm), however the compiler will not always list the attributes in MSIL in the same order that they appear in source code. I couldn’t figure out any formula as to how the compiler decides what order to put them in – but maybe it will be possible to predict the behavior (at least in the current version) after some more detailed analysis or some help from someone in the compiler teams.

    In any event, the order that attribute-defined handlers show in the Effective Policy Viewer tool is the same as the the order they will execute in.


  3. Daniel Melo says:


    What if there was an "order" parameter for the handlers?



    public IList GetSomeData() { }

    In this case validation handler would run before cache handler because the order parameter defined that. No matter wich order the reflexion API would return them.

    Actually I suggested it few posts ago.

    I think this is a very important feature, because I believe that in most of the cases the handlers to be applied are known in compile time and should not be changed in runtime.


  4. Thanks Daniel – agree this is a good idea given the way the .NET reflection APIs behave. Unfortunately we didn’t have time to add any new features in the release at the time you originally suggested it, but it looks like a great thing to add in the future.


  5. Enterprise Library 3.0patterns & practices Developer Center The patterns & practices Enterprise…

  6. Beramode says:

    There is "Constructor not found" exception when running programs using my own custom call handler for policy injection application block.

    The Constuctor cannot be found due to the use of NameValueCollection at the 2nd argument castedObjectConfiguration.Attributes of Activator.CreateInstance() inside CustomerProviderAssembler.cs

    public TObject Assemble(IBuilderContext context, TConfiguration objectConfiguration, IConfigurationSource configurationSource, ConfigurationReflectionCache reflectionCache)


    TConcreteConfiguration castedObjectConfiguration = (TConcreteConfiguration)objectConfiguration;

    TObject provider

    = (TObject)Activator.CreateInstance(objectConfiguration.Type, castedObjectConfiguration.Attributes);

    return provider;


  7. Chris Tavares says:


    If you are using the CustomCallHandlerData to configure your own handler, you’ll need to add a constructor to the handler that takes a NameValueCollection as a parameter. That’s just the way it works. This should be documented better.

    The other option would be to create a configuration data class and assembler for your custom call handler. This has the advantage of showing exactly what your configuration options are in the config tool.

  8. Michael Lang says:

    Hi Tom,

    Sorry this question isn’t related to your blog entry.

    I have a couple of custom exception handlers, I can edit my config and add my handlers no problems with the EntLibConfig.exe tool.

    However when I attempt to use editor integrated into Visual Studio it doesn’t seem to know about my custom exception handlers.  Any hints on how you can get this to work?

  9. Better late than never… I have combined the last 3 weeks. In the pipeline: So much is in the pipeline

Comments are closed.

Skip to main content