In SharePoint, The SafeControl list is defined in the web.config and is a white list of controls that can be placed onto a SharePoint page.

The other day I was packaging my solution using WSPBuilder, deploying the WSP, and found that somehow the EntLib ExceptionHandling DLL was being added to the SafeControl list by the deployment. This was causing errors for my site. The ExceptionHandling DLL is being referenced by my project, but was not intended to be added to the SafeControl list.

I looked closer at the output window in Visual Studio and noticed this message from WSPBuilder:

———–
Adding assembly: Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll
Could not resolve: Microsoft.Practices.Unity, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35. Please define the -DLLReferencePath with the path to the referenced assemblies. However a SafeControl tag for the Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.Unity.ExceptionHandlingBlockExtension class has been created.

SafeControls added: 1
———–

So WSPBuilder added the EntLib DLL to the SafeControl automatically. But why?

The class ExceptionHandlingBlockExtension inherits from a base class in the Unity DLL. My reason is that because WSPBuilder could not locate the Unity DLL, it could not work out whether the ExceptionHandlingBlockExtension SHOULD be in the SafeControl list (e.g. is it inheriting from a Control class?), and hence it went ahead and add it to the list anyway.

The other interesting thing is even if I include the Unity DLL in the WSP (i.e. I do this by ensuring that the Unity DLL is copied to the project’s bin folder before running WSPBuilder), WSPBuilder still cannot locate the DLL.

I have found that WSPBuilder will only locate the DLL if the DLL is in the GAC, or if the DLLReferencePath setting is used.

To use the DLLReferencePath, one way would be to create a WSPBuilder.exe.config file at the root of your project and then specify the DLLReferencePath as a key in the appSettings section.