Namespace problem with PIAB in EntLib 4.1

Topics: Policy Injection Application Block
May 22, 2009 at 5:54 PM


I would like to migrate my code to Enterprise Library 4.1, but I am having trouble with my existing PIAB code. When I change the assemblies from EntLib 3.1 to EntLib 4.1, none of my PIAB code compiles; it says it can't find any of the classes and interfaces from the PolicyInjection namespace in the PolicyInjection assembly. The only way that I can get this code to compile is to include references to the Unity.Interception assembly and to use the Unity.InterceptionExtension namespace. Did the namespace change for the PIAB classes and interfaces in EntLib 4.1? Is the behavior different? The source code for the PIAB seems to be the same as far as the namespaces are concerned.

To build the assemblies, I just double-clicked "BuildAndCopyAssemblies.bat" from the Scripts folder; I then copied those DLLs into the folder from which I reference the Enterprise Library assemblies. Am I doing something wrong here?

Thanks very much for your help,


- Daniel

May 23, 2009 at 5:20 AM

Yes, this changed in Entlib 4.1. We moved the core infrastructure for interception into the Unity interception extension. The call handlers that reference Entlib are still in the PolicyInjection.CallHandlers.dll. So you'll need to add the references to the Unity assemblies as well.

I apologize, we should have documented this change better than we did.


May 26, 2009 at 1:25 PM

Apparently, the PolicyInjector and PolicyInjectorFactory classes are removed from the PolicyInjection namespace as well (in fact, there's pretty much nothing left in the PolicyInjection namespace, but not all of the classes that were in that namespace appear to have made it to the new Unity assembly). I was relying on these classes in some of my existing code. Have these classes been removed because of an implementation change in the new Unity interceptor assemblies? I have a number of custom handlers and other PIAB extensions; will these custom classes be affected by any such changes? Are there any additional steps required to migrate existing PIAB code from 3.1 to 4.1?

Thanks again for your help,


- Daniel

May 28, 2009 at 10:00 PM

The PolicyInjector was removed for a couple of reasons. It was intended as an extension point, but we never actually implemented any other injectors. When I tried, I realized the API for the injectors was actually all wrong, and it would be very difficult to actually implement a different injection mechanism. Since there were no actual uses as an extension point, we removed it. And without the Injector, the Factory had no reason to exist either. At this point, all the interception infrastructure runs through the Unity chain. If you could share how you were using the old Injector classes, I'm sure I can come up with the equivalent usage.

As far as custom callhandlers go, they should still just work. They'll probably require a recompile and some reference updates, but that should be it. Your other PIAB extensions may or may not work, depending on what they do and how they extend things. Again, it'll depend on the details.


Jun 1, 2009 at 2:24 PM

Thanks for getting back to me. Your explanation makes a lot of sense. I was using the factories and injectors mostly to avoid the caching of policies that the PolicyInjection facade hides (for testing purposes). By looking at the source code for EntLib 4.1, I found that I could do this by creating a new IConfigurationSource instance and passing it into the calls I made to the PolicyInjection facade. Since this is just test code, I don't mind taking the hit of creating a new configuration source all the time, but it might be a nice addition in the future to provide some kind of access to the facade's caching features.

So far, it looks like all of my existing PIAB code still works the same way except for one detail: previously, I threw a very specific exception when one of my custom handlers couldn't be created. I had a unit test that checked for this exception to make sure that the error condition was being handled properly. It seems now that my exception is intercepted and then rethrown as part of a new Unity exception. I would prefer if my exception (or an exception which derived from my base exception class) were the one that the calling code had to handle; is it possible for me to make this happen, and if so, what is the best way to do it?

Thanks again,


- Daniel

Jun 5, 2009 at 7:34 AM

We don't have a mechanism to customize which exceptions are thrown when a resolve fails. However, if it failed due to an exception, that exception is always kept inside the InnerException (although it might be a few, or more than a few, levels down :-)). While not ideal, you could get the ResolutionFailedException, and dig through InnerExceptions until you got to your exception type (or not). Then you could either rethrow it or just process it right there.