Problem using EntLib from within MS Office Excel Addin

Topics: Enterprise Library Core, Exception Handling Application Block, Logging Application Block
Jan 11, 2008 at 4:56 PM

We are at a decision point on whether to abandon the use of EntLib due to this problem. I hope someone can help.

We have a class library DLL (called XFDataSource.dll) that uses EntLib. XFDataSource.dll may be used by many apps. For this reason, XFDataSource uses FileConfigurationSource to allow EntLib to use a config file specific to XFDataSource. The intent is to keep XFDataSource's config file separate from the config files of the apps that use XFDataSource.

This has been working great when the app that references XFDataSource is a standard exe (e.g. WinForms or Console app). But now we need an MS Office excel addin to reference XFDataSource and we are getting the exception below when attempting to obtain a default Exception Policy...

(Note: I will provide more background on the excel addin further down ...)

"System.Configuration.ConfigurationErrorsException: The type Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version=, Culture=neutral, PublicKeyToken=null from configuration could not be created. (C:\Documents and Settings\tsvicker\Local Settings\Application Data\assembly\dl3\L3XEXKKY.EH2\R1CQD4KK.44Y\d7181eba\f3960cf0_3d52c801\XFDataSource.dll.config line 54)
at System.Configuration.BaseConfigurationRecord.EvaluateOne(String[] keys, SectionInput input, Boolean isTrusted, FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult)
at System.Configuration.BaseConfigurationRecord.Evaluate(FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult, Boolean getLkg, Boolean getRuntimeObject, Object& result, Object& resultRuntimeObject)
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.Configuration.GetSection(String sectionName)
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSourceImplementation.GetSection(String sectionName)
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource.GetSection(String sectionName)
at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.ExceptionHandlingSettings.GetExceptionHandlingSettings(IConfigurationSource configurationSource)
at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionHandlingConfigurationView.get_ExceptionHandlingSettings()
at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionHandlingConfigurationView.GetExceptionPolicyData(String policyName)
at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionPolicyCustomFactory.GetConfiguration(String id, IConfigurationSource configurationSource)
at Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionPolicyCustomFactory.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, String id, IConfigurationSource configurationSource)
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.LocatorNameTypeFactoryBase`1.Create(String name)
at XFDataSource.Utils.EntLib..cctor() -- check Windows Event Viewer for more information. at XFDataSource.AnalyticsImpls.DictionaryInit.execute(Dictionary`2 xfDictionary, Hashtable concepts)
at XFDataSource.AnalyticsImpls.XFDictionary..cctor()"

Here is a code snippet from XFDataSource.Utils.EntLib..cctor() where it is failing:

sEntLibConfigSource = new FileConfigurationSource(ConfigFile.FilePath);
ExceptionPolicyFactory exceptionFactory =
new ExceptionPolicyFactory(sEntLibConfigSource);
sEntLibDefaultExceptionPolicy = exceptionFactory.Create("Default Policy");

Here is the related snippet of the config file at C:\Documents and Settings\tsvicker\Local Settings\Application Data\assembly\dl3\L3XEXKKY.EH2\R1CQD4KK.44Y\d7181eba\f3960cf0_3d52c801\XFDataSource.dll.config line 54).

<?xml version="1.0" encoding="utf-8"?>

<section name="exceptionHandling" type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.ExceptionHandlingSettings, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=, Culture=neutral, PublicKeyToken=null" />

<add name="Default Policy">
<add type="System.Exception, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089"
postHandlingAction="None" name="Exception">
<add logCategory="General" eventId="100" severity="Error" title="Enterprise Library Exception Handling"
formatterType="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.TextExceptionFormatter, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=, Culture=neutral, PublicKeyToken=null"
priority="0" type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler,
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version=, Culture=neutral, PublicKeyToken=null"
name="Logging Handler" />

We use the EntLib config tool so there should be no corruption as a result of human intervention.

The exception message simply says "Type .. LogginExceptionHandler ... could not be created". How can I get more info to understand what the real problem is ? I looked at all the inner exceptions and this is the best I can get.

Regarding background on the excel addin, we are using Visual Studio Tools for Office, Second Edition (VSTO SE) to create the addin. VSTO SE is a plugin to Visual Studio 2005 that allows us to use the IDE to develop the excel addin. When the addin is built and invoked (from within excel), the addin puts DLLs that it references into directories under the user's Docuements and Settings. These end up being the locations from which the DLLs (like XFDataSource) are executed from, unfortunately. So one of our 1st discoveries is that we had to copy all the EntLibs that XFDataSource uses (along with XFDataSource.dll.config file) into the directory under Documents and Settings in order for EntLib to be called. (We are still prototyping and need to figure out how to do this cleanly for deployment purposes.) The reason the config file is copied there is that the XFDataSource always expects its config file to reside in the same direcory that XDataSource.dll resides in, thus this is why the Exception shows that ugly directory under Documents and Settings.

There have been several other posts in CodePlex with an exception similar to this. The one from Nov 4, 2007 is very similar. But I still haven't been able to find a solution. I am guessing it is some kind of trust issue where the Excel addin, the XFDataSource, and EntLib are not in sync.

I would be happy to provide more info. Thanks in advance for any help you can provide.

Tom Vicker

Jan 11, 2008 at 9:24 PM
I found the problem. It turns out that any assemblies that are used by a VSTO addin must be fully trusted. To ensure this happens, you have to create a code group with URL evidence and point the URL to the the bin/Debug or bin/Release directory of the VSTO addin project. All the assemblies that are needed by the VSTO addin must be in the folder, even if they are not directly referenced from the VSTO project (like the Enterprise Library assemblies).

To create the code group, refer to article at this location:

It took me 3 days to figure this out. I just about gave up hope.