Database logging failing Error-dependency failed, type = "Microsoft.Practices.EnterpriseLibrary.Logging.LogWriter", name = "(none)"

Topics: Logging Application Block
Jul 26, 2012 at 5:13 PM
Edited Jul 26, 2012 at 7:03 PM


I have an application built using Ent Lib 5.0 and logging to the event log.  We are now at the point when we want to move to logging to a SQL server DB as we are going to QA on a load balanced environment.  I have added a new logging configuration listner and added the connection string section to my configuration file.  I also tried to add a data configuration section but I am still getting errors.  I have included a copy of the configuration file and the error.

Any help would be much appreciated,

Monitoring the DB show no tracing activity or failed connections.  This suggests EntLib can not locate the DB connection string.

<?xml version="1.0"?>
  <section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=6e010e0ac1025666" requirePermission="true" />
  <section name="dataConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings, Microsoft.Practices.EnterpriseLibrary.Data, Version=5.0.505.0, Culture=neutral, PublicKeyToken=6e010e0ac1025666" requirePermission="true" />
  <dataConfiguration defaultDatabase="TempDbLogSink"></dataConfiguration>
 <loggingConfiguration name="" tracingEnabled="true" defaultCategory="General">
   <add name="Event Log Listener" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FormattedEventLogTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=6e010e0ac1025666"
    listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FormattedEventLogTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=6e010e0ac1025666"
   source="ISL Tracing" formatter="Text Formatter" log="" machineName="." traceOutputOptions="None" />
   <add name="SqlTraceListener" type="Microsoft.Practices.EnterpriseLibrary.Logging.Database.FormattedDatabaseTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging.Database, Version=5.0.505.0, Culture=neutral, PublicKeyToken=6e010e0ac1025666"
    listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Database.Configuration.FormattedDatabaseTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging.Database, Version=5.0.505.0, Culture=neutral, PublicKeyToken=6e010e0ac1025666"
     formatter="Text Formatter" />
   <add type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=6e010e0ac1025666"
    template="Timestamp: {timestamp}{newline}&#xA;Message: {message}{newline}&#xA;Category: {category}{newline}&#xA;Priority: {priority}{newline}&#xA;EventId: {eventid}{newline}&#xA;Severity: {severity}{newline}&#xA;Title:{title}{newline}&#xA;Machine: {localMachine}{newline}&#xA;App Domain: {localAppDomain}{newline}&#xA;ProcessId: {localProcessId}{newline}&#xA;Process Name: {localProcessName}{newline}&#xA;Thread Name: {threadName}{newline}&#xA;Win32 ThreadId:{win32ThreadId}{newline}&#xA;Extended Properties: {dictionary({key} - {value}{newline})}"
   name="Text Formatter" />
   <add switchValue="All" name="Default">
     <add name="Event Log Listener" />
   <add switchValue="All" name="CustomerPortfolioRequested">
     <add name="SqlTraceListener" />
   <add switchValue="All" name="CustomerPortfolioUpdated">
     <add name="Event Log Listener" />
   <add switchValue="All" name="General">
     <add name="Event Log Listener" />
   <allEvents switchValue="All" name="All Events" />
   <notProcessed switchValue="All" name="Unprocessed Category" />
   <errors switchValue="All" name="Logging Errors &amp; Warnings">
     <add name="Event Log Listener" />
  <!--add name="TempDbLogSink" connectionString="Integrated Security=SSPI;Initial Catalog=Logging;Data Source=ISLDev-bt-b" providerName="System.Data.SqlClient" /-->
  <add name="TempDbLogSink" connectionString="Data Source=ISLDev-bt-b;Initial Catalog=Logging;User ID=XXXXX;Password=XXXXXX" providerName="System.Data.SqlClient" />

Exception Message:
Activation error occured while trying to get instance of type LogWriter, key ""
 Inner Exception: Resolution of the dependency failed, type = "Microsoft.Practices.EnterpriseLibrary.Logging.LogWriter", name = "(none)".
Exception occurred while: while resolving.
Exception is: InvalidOperationException - The type Database cannot be constructed. You must configure the container to supply this value.
At the time of the exception, the container was:

  Resolving Microsoft.Practices.EnterpriseLibrary.Logging.LogWriterImpl,LogWriter.__default__ (mapped from Microsoft.Practices.EnterpriseLibrary.Logging.LogWriter, (none))
  Resolving parameter "structureHolder" of constructor Microsoft.Practices.EnterpriseLibrary.Logging.LogWriterImpl(Microsoft.Practices.EnterpriseLibrary.Logging.LogWriterStructureHolder structureHolder, Microsoft.Practices.EnterpriseLibrary.Logging.Instrumentation.ILoggingInstrumentationProvider instrumentationProvider, Microsoft.Practices.EnterpriseLibrary.Logging.ILoggingUpdateCoordinator updateCoordinator)
    Resolving Microsoft.Practices.EnterpriseLibrary.Logging.LogWriterStructureHolder,LogWriterStructureHolder.__default__ (mapped from Microsoft.Practices.EnterpriseLibrary.Logging.LogWriterStructureHolder, (none))
    Resolving parameter "traceSources" of constructor Microsoft.Practices.EnterpriseLibrary.Logging.LogWriterStructureHolder(System.Collections.Generic.IEnumerable`1[[Microsoft.Practices.EnterpriseLibrary.Logging.Filters.ILogFilter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=6e010e0ac1025666]] filters, System.Collections.Generic.IEnumerable`1[[System.String, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089]] traceSourceNames, System.Collections.Generic.IEnumerable`1[[Microsoft.Practices.EnterpriseLibrary.Logging.LogSource, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=6e010e0ac1025666]] traceSources, Microsoft.Practices.EnterpriseLibrary.Logging.LogSource allEventsTraceSource, Microsoft.Practices.EnterpriseLibrary.Logging.LogSource notProcessedTraceSource, Microsoft.Practices.EnterpriseLibrary.Logging.LogSource errorsTraceSource, System.String defaultCategory, System.Boolean tracingEnabled, System.Boolean logWarningsWhenNoCategoriesMatch, System.Boolean revertImpersonation)
      Resolving Microsoft.Practices.EnterpriseLibrary.Logging.LogSource,CustomerPortfolioRequested
      Resolving parameter "traceListeners" of constructor Microsoft.Practices.EnterpriseLibrary.Logging.LogSource(System.String name, System.Collections.Generic.IEnumerable`1[[System.Diagnostics.TraceListener, System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089]] traceListeners, System.Diagnostics.SourceLevels level, System.Boolean autoFlush, Microsoft.Practices.EnterpriseLibrary.Logging.Instrumentation.ILoggingInstrumentationProvider instrumentationProvider)
        Resolving Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.ReconfigurableTraceListenerWrapper,SqlTraceListener (mapped from System.Diagnostics.TraceListener, SqlTraceListener)
        Resolving parameter "wrappedTraceListener" of constructor Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.ReconfigurableTraceListenerWrapper(System.Diagnostics.TraceListener wrappedTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging.ILoggingUpdateCoordinator coordinator)
          Resolving Microsoft.Practices.EnterpriseLibrary.Logging.Database.FormattedDatabaseTraceListener,SqlTraceListener?implementation (mapped from System.Diagnostics.TraceListener, SqlTraceListener?implementation)
          Resolving parameter "database" of constructor Microsoft.Practices.EnterpriseLibrary.Logging.Database.FormattedDatabaseTraceListener(Microsoft.Practices.EnterpriseLibrary.Data.Database database, System.String writeLogStoredProcName, System.String addCategoryStoredProcName, Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.ILogFormatter formatter)
            Resolving Microsoft.Practices.EnterpriseLibrary.Data.Database,TempDbLogSink

 Inner Exception: The type Database cannot be constructed. You must configure the container to supply this value.

the message resource is present but the message is not found in the string/message table

Jul 27, 2012 at 6:33 AM

The configuration file looks OK.  When this message appears usually it means that the connection string is not set up.  There's a some other common things that could be wrong but a different exception would be raised.  I'm assuming the posted configuration is in the app.config; is that correct?

Does Data Access work on it's own using that configuration file and the TempDbLogSink database?  

Randy Levy
Enterprise Library support engineer 

Jul 28, 2012 at 2:43 AM

Hi Randy,

Thanks for validating the configuration for me.  The configuration file is an Enterprise Library configuration file.  We have a line in the machine config file to redirect the enterprise library references to this file.  We know the code is using this file as it picks up the TempDbLogSink name.  My thought is that although the configuration is working for the logging, the code is looking else were when trying to do data access.


Jul 28, 2012 at 4:02 AM

So the posted configuration file is a stand alone configuration file (e.g. entlib.config or something like that).  Can you post the machine.config redirect?  Does your app have a configuration file?  Does it have any enterprise library or connection string entries in it?

Randy Levy
Enterprise Library support engineer 

Jul 30, 2012 at 5:14 PM

Hi Randy,

The application is part of a BizTalk solution.  The BTSNTSvc.exe.config file is the default file and does not have any database connection information. 

Machine.config (same code in the framework 4.0 32 and 64 bit config file versions)
        <section name="ait.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=5.0.505.0, Culture=neutral, PublicKeyToken=6e010e0ac1025666" requirePermission="true"/>

 <ait.ConfigurationSource selectedSource="ISL File-based Configuration Source">
   <add name="ISL File-based Configuration Source" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=5.0.505.0,Culture=neutral, PublicKeyToken=6e010e0ac1025666" filePath="C:\Program Files (x86)\ISL\isl.config"/>

Could the data connection code be using a different framework configuration file??


Jul 30, 2012 at 6:15 PM

The configuration itself looks good.  A quick test without BizTalk but an equivalent configuration (machine.config with external config file) works fine.  I'm assuming you are running BizTalk 2010 -- is that correct?  I'm also assuming you are compiling your code against .NET Framework 4 (not Client Profile).

Since you say you have configured both 32 and 64 bit machine.configs then I'm just wondering if, for some reason, another framework version besides .NET 4 is running for that service?  Can you verify?  For example,

Randy Levy
Enterprise Library support engineer 

Jul 30, 2012 at 11:32 PM

Thanks Randy for your help with this,

Yes, this is a BTS 2010 server.    I ran the Process Explorer tool and checked the dlls that are running under the BTS service account.  It looks like everything is running in the 32 bit .Net 4.0 Framework. 

If the code is compiled against .Net 4.0 client profile it fails quickly, so I'm know that that is configured correctly.


Aug 2, 2012 at 4:02 AM

It all looks good.  What if you create a simple console application -- can you replicate the issue with that?  E.g. use the machine.config that references the isl.config and see if the following works:

    class Program
        static void Main(string[] args)
            var logger = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();
            logger.Write("Test", "CustomerPortfolioRequested");

Randy Levy
Enterprise Library support engineer 

Aug 8, 2012 at 1:20 PM

I have the same problem. I am also doing it in BizTalk and it works for logging to event viewer, but not when logging to a database.

I tried config etc in regular .net program and there it worked. So it must be something in BizTalk, but no idea where to start looking :(

Aug 8, 2012 at 10:56 PM

Some questions:

  • Can you recreate the issue using a console application with the same configuration as BizTalk on the BizTalk host instance server?  
  • Are you sure that the process is executing on a host that is properly configured (e.g. perhaps one BizTalk host instance (server) is configured properly but another is not?)
  • Are you using Data Access within BizTalk?  If so, is that working?
  • What happens if you simply embed all configuration within the btsntsvc.exe.config file?

Randy Levy
Enterprise Library support engineer 

Aug 13, 2012 at 8:19 AM

My apologies for my late response. 

  • Can you recreate the issue using a console application with the same configuration as BizTalk on the BizTalk host instance server?  I tried something similar in the past, but i 'll try it again with the config file of bizTalk.
  • Are you sure that the process is executing on a host that is properly configured (e.g. perhaps one BizTalk host instance (server) is configured properly but another is not?) Pretty sure of that, because i have no problems with other functionality
  • Are you using Data Access within BizTalk?  If so, is that working? I contact a custom database in BizTalk, on the same location as i do logging (orchestration), with connectionstring in btsntsvc.exe.config and that works without problems.
  • What happens if you simply embed all configuration within the btsntsvc.exe.config file? It is located in that file. ( was something that came back in several other threads)


Aug 13, 2012 at 10:02 AM
Edited Aug 13, 2012 at 10:03 AM

I got the same error in my console app and in the examples on the site, and that made me wonder wy it worked in the past. Then i saw this new thread : where data.dll must be in the console folder. And that is the reason. Everything is gac'ed here, because of usage in biztalk and he does not find the data.dll.  When i put it in the folder of the console application, he finds it. For BizTalk, it is not an option to put it somewhere in a folder, it must be gac'ed :/


I'll post in the other thread my fuslogvw.exe

Aug 13, 2012 at 1:00 PM

I made it work by placing the data.dll in the biztalk installation folder.This way, he gets passes the physical step and then he takes the gac version.

Thx for help!

Aug 13, 2012 at 3:53 PM
Edited Aug 13, 2012 at 4:01 PM

This looks like an existing issue with loading assemblies in the GAC.  See  The posted solution is to fully qualify the assembly:


  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <qualifyAssembly partialName="Microsoft.Practices.EnterpriseLibrary.Data" fullName="Microsoft.Practices.EnterpriseLibrary.Data, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>


Sorry for not digging that up sooner and hopefully that helps.

Randy Levy
Enterprise Library support engineer