Using Entlib

Topics: Building and extending application blocks, Logging Application Block, Policy Injection Application Block
Jun 14, 2007 at 5:59 PM
Hi,
I just installed the entlib 3.1 and try to use it in a project (policy injection with logging), however I get an error that PolicyInjection.dll assembly can not be loaded. I noticed that the assemblies are not installed in GAC.
Jun 14, 2007 at 11:35 PM
Hi,

Can you provide additional information about your project structure and the load failure message? Does it fail when building or at run time?

It shouldn't be necessary to install the assemblies in the GAC, but keep in mind that all the blocks in the Enterprise Library have dependencies to both ObjectBuilder and the Enterprise Library core assemblies; does your project have references to these assemblies as well as the assembly for the PIAB?

Fernando


Maksim wrote:
Hi,
I just installed the entlib 3.1 and try to use it in a project (policy injection with logging), however I get an error that PolicyInjection.dll assembly can not be loaded. I noticed that the assemblies are not installed in GAC.

Jun 15, 2007 at 2:44 PM
Hi Fernando,
It's a very simple project - console application with a couple of classes. I've included Common.dll, ObjectBuilder.dll, PolicyInjection.dll, PolicyInjection.CallHandlers.dll, and Logging.
I get a runtime error:
System.Configuration.ConfigurationErrorsException was unhandled
Message="An error occurred creating the configuration section handler for policyInjection: Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.PolicyInjection, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) (C:\\Documents and Settings\\Maksim Pogorelov\\My Documents\\Visual Studio 2005\\Projects\\ConsoleApplication1\\ConsoleApplication1\\bin\\Debug\\ConsoleApplication1.vshost.exe.config line 4)"
Source="System.Configuration"
BareMessage="An error occurred creating the configuration section handler for policyInjection: Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.PolicyInjection, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"
Filename="C:\\Documents and Settings\\Maksim Pogorelov\\My Documents\\Visual Studio 2005\\Projects\\ConsoleApplication1\\ConsoleApplication1\\bin\\Debug\\ConsoleApplication1.vshost.exe.config"
Line=4
StackTrace:
at System.Configuration.BaseConfigurationRecord.FindAndEnsureFactoryRecord(String configKey, Boolean& isRootDeclaredHere)
at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
at System.Configuration.BaseConfigurationRecord.GetSection(String configKey, Boolean getLkg, Boolean checkPermission)
at System.Configuration.BaseConfigurationRecord.GetSection(String configKey)
at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(String sectionName)
at System.Configuration.ConfigurationManager.GetSection(String sectionName)
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.SystemConfigurationSourceImplementation.GetSection(String sectionName)
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.SystemConfigurationSource.GetSection(String sectionName)
at Microsoft.Practices.EnterpriseLibrary.PolicyInjection.PolicyInjectorCustomFactory.CreateObject(IBuilderContext context, String name, IConfigurationSource configurationSource, ConfigurationReflectionCache reflectionCache)
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.ConfiguredObjectStrategy.BuildUp(IBuilderContext context, Type t, Object existing, String id)
at Microsoft.Practices.ObjectBuilder.BuilderStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild)
at Microsoft.Practices.ObjectBuilder.SingletonStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild)
at Microsoft.Practices.ObjectBuilder.BuilderStrategy.BuildUp(IBuilderContext context, Type typeToBuild, Object existing, String idToBuild)
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.ConfigurationNameMappingStrategy.BuildUp(IBuilderContext context, Type t, Object existing, String id)
at Microsoft.Practices.ObjectBuilder.BuilderBase`1.DoBuildUp(IReadWriteLocator locator, Type typeToBuild, String idToBuild, Object existing, PolicyList[] transientPolicies)
at Microsoft.Practices.ObjectBuilder.BuilderBase`1.BuildUp(IReadWriteLocator locator, Type typeToBuild, String idToBuild, Object existing, PolicyList[] transientPolicies)
at Microsoft.Practices.ObjectBuilder.BuilderBase`1.BuildUpTTypeToBuild(IReadWriteLocator locator, String idToBuild, Object existing, PolicyList[] transientPolicies)
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.EnterpriseLibraryFactory.BuildUpT(IReadWriteLocator locator, IConfigurationSource configurationSource)
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.EnterpriseLibraryFactory.BuildUpT(IConfigurationSource configurationSource)
at Microsoft.Practices.EnterpriseLibrary.PolicyInjection.PolicyInjectorFactory.Create()
at Microsoft.Practices.EnterpriseLibrary.PolicyInjection.PolicyInjection.GetInjectorFromConfig(IConfigurationSource configurationSource)
at Microsoft.Practices.EnterpriseLibrary.PolicyInjection.PolicyInjection.get_DefaultPolicyInjector()
at Microsoft.Practices.EnterpriseLibrary.PolicyInjection.PolicyInjection.CreateTObject(Object[] args)
at ConsoleApplication1.Program.Main(String[] args) in C:\Documents and Settings\Maksim Pogorelov\My Documents\Visual Studio 2005\Projects\ConsoleApplication1\ConsoleApplication1\Program.cs:line 22
at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

Thanks
Jun 15, 2007 at 3:28 PM
The error is generated in this function:

public class SystemConfigurationSourceImplementation : BaseFileConfigurationSourceImplementation
{
....
public override ConfigurationSection GetSection(string sectionName)
{
ConfigurationSection configurationSection = ConfigurationManager.GetSection(sectionName) as ConfigurationSection;
...blows after this line

}
}
Jun 17, 2007 at 8:43 AM
Edited Aug 29, 2007 at 10:29 PM
The problem is that the EntLib configuration tool is using different references than your project does. By default it uses MS-signed dlls, while I guess you're using unsigned (or signed by you) references in your project. I've had the same problem, please look at http://vladimirkofman.com/archive/2007/06/13/entlib-3-1-configuration-2.aspx
Jun 18, 2007 at 3:56 PM
Vladimir,
could you post the answer here or email me from your blog. My company blocks your link. thanks
Jun 18, 2007 at 4:24 PM
Edited Jun 18, 2007 at 6:48 PM
What I've found is that EntLib is installed with two distinct copies of the library dlls: one signed with the MS-issued key (C:\EntLib3Src\App Blocks\bin), and another one unsigned (C:\Program Files\Microsoft Enterprise Library 3.1 - May 2007\Bin).
By default VS-integrated configuration tool will use MS-signed assemblies, and will create sections in the .config file in the following format (policyInjection is just an example, the same is true for all EntLib App Blocks):

...<section name="policyInjection" type="Microsoft.Practices.EnterpriseLibrary.PolicyInjection.Configuration.PolicyInjectionSettings, Microsoft.Practices.EnterpriseLibrary.PolicyInjection, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />...

So, if your project uses references to unsigned EntLib dlls you'll get "The located assembly's manifest definition does not match the assembly reference" kind of errors at runtime.

Fortunately, there's an option in a solution properties to define what version you want the configuration tool to use: Go to your solution properties, you should see EntepriseLibraryConfigurationSet property (values are: 'Microsoft Signed', 'EntLib3Src', '(machine default)').

To avoid runtime errors you need to make sure that your references are matching the above setting (BTW you're welcome to count the spelling mistakes in the message http://farm2.static.flickr.com/1251/548984512_9b80d9f180_o.jpg you get when you try to modify this setting).
Jun 19, 2007 at 6:27 PM

VladimirK wrote:
What I've found is that EntLib is installed with two distinct copies of the library dlls: one signed with the MS-issued key (C:\EntLib3Src\App Blocks\bin), and another one unsigned (C:\Program Files\Microsoft Enterprise Library 3.1 - May 2007\Bin).
By default VS-integrated configuration tool will use MS-signed assemblies, and will create sections in the .config file in the following format (policyInjection is just an example, the same is true for all EntLib App Blocks):

...<section name="policyInjection" type="Microsoft.Practices.EnterpriseLibrary.PolicyInjection.Configuration.PolicyInjectionSettings, Microsoft.Practices.EnterpriseLibrary.PolicyInjection, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />...

So, if your project uses references to unsigned EntLib dlls you'll get "The located assembly's manifest definition does not match the assembly reference" kind of errors at runtime.

Fortunately, there's an option in a solution properties to define what version you want the configuration tool to use: Go to your solution properties, you should see EntepriseLibraryConfigurationSet property (values are: 'Microsoft Signed', 'EntLib3Src', '(machine default)').

To avoid runtime errors you need to make sure that your references are matching the above setting (BTW you're welcome to count the spelling mistakes in the message http://farm2.static.flickr.com/1251/548984512_9b80d9f180_o.jpg you get when you try to modify this setting).



Thank you. Once I added references from c:\Program Files\Enterprise Libreary...\bin folder, the problem went away.