Bug in PIAB handler pipeline in April release?

Topics: Policy Injection Application Block
Apr 6, 2007 at 8:41 PM
I just downloaded Enterprise Library 3.0 and updated my test/sample/protoype project with the new references.

After adjusting for the slight difference in configuration for the MatchingRuleData, I've discovered that my Handler for a given policy is actually executing twice. I've used a base app.config file, and my own custom building of a DictonaryConfigurationSource code. It happens with either implementation. It also doesn't matter if I reference from the install bin folder, or from the debug binaries from the src install.

Am I doing something wrong?
Apr 6, 2007 at 8:56 PM
Assuming everything's working correctly, the most likely cause is that there's multiple policies specifying the same handler class. In that case you'll get two instances of the same handler.

Would it be possible to send me something that reproduces the problem that I can take a look at? A full project would be nice, but the config file(s) plus the object that you're applying the policy to would be sufficient.

Apr 6, 2007 at 8:59 PM
Yes, it would be very possible. Also, I only have the one policy and handler defined.

Where should I send it to?

Apr 6, 2007 at 10:01 PM
Please send it to <myprofilename>@microsoft.com. Profile name is at the left.


Apr 9, 2007 at 6:31 PM
Edited Apr 9, 2007 at 6:32 PM
Thanks for the report; this is indeed a bug in how policies get applied to methods that implement interfaces. For the benefit of the rest of our community, I'll summarize the situation and how to work around it.

The issue arises when using a policy that only has a single MemberNameMatchingRule, that matches a method implemented by an interface. For example:

public interface IOne
    void Foo();
public class One : IOne
    void Foo() { }

If your policy specifies a MemberNameMatchingRule, matching "Foo", then the policy in question will actually match twice: once on One.Foo, and again on IOne.Foo.

We're figuring out what the fix needs to be to the underlying problem, but in the meantime the workaround is to add a second matching rule to constrain which methods match. So if you wanted to match any implementation of IOne.Foo, add a TypeMatchingRule that matches IOne. That way, the policy would not match One.Foo, and you end up with only one handler in your pipeline.

Thanks for the bug report!