Activation error occured while trying to get instance of type ExceptionManager

Topics: Exception Handling Application Block
Jun 2, 2011 at 8:55 PM

I'm creating a powershell cmdlet so that I can capture exception data from powershell scripts and send it off through the exception handling block to a queue, but I'm having some issues getting this to work. I've been working from the assumption that cmdlets have to be loaded from a DLL, therefore I have to specify an outside configuration file since there's no app.config by default. Here's the code I'm trying to call:


Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource config = new Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource("Widgit.EnterpriseLibraryCmdlet.dll.config");
ExceptionManager  exManager = EnterpriseLibraryContainer.CreateDefaultContainer(config).GetInstance<ExceptionManager>();
exManager.HandleException(exception, Policy);



<?xml version="1.0" encoding="utf-8" ?>
    <section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="true" />
    <section name="exceptionHandling" type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.ExceptionHandlingSettings, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="true" />
  <loggingConfiguration name="" tracingEnabled="true" defaultCategory="General">
      <add name="Message Queuing Trace Listener" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.MsmqTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.MsmqTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        queuePath="machine\private$\widget" formatter="Binary Log Message Formatter"
        timeToBeReceived="49710.06:28:15" useAuthentication="false"
        traceOutputOptions="None" />
      <add type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.BinaryLogFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        name="Binary Log Message Formatter" />
      <add switchValue="All" autoFlush="false" name="General">
          <add name="Message Queuing Trace Listener" />
      <add switchValue="All" autoFlush="false" name="TestCategory">
          <add name="Message Queuing Trace Listener" />
      <allEvents switchValue="All" name="All Events" />
      <notProcessed switchValue="All" name="Unprocessed Category" />
      <errors switchValue="All" name="Logging Errors &amp; Warnings">
          <add name="Message Queuing Trace Listener" />
      <add name="TestPolicy">
          <add name="All Exceptions" type="System.Exception, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089"
              <add name="Logging Exception Handler" type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
                logCategory="General" eventId="100" severity="Error" title="Enterprise Library Exception Handling"
                formatterType="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.TextExceptionFormatter, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling"
                priority="0" />


However, I get the following exception when trying to run this from the cmdlet:

Message: Activation error occured while trying to get instance of type ExceptionManager, key ""Data           : {}InnerException : Microsoft.Practices.Unity.ResolutionFailedException: Resolution of the dependency failed, type = "Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ExceptionManager", name = "(                 none)".                 Exception occurred while: while resolving.                 Exception is: InvalidOperationException - The type ExceptionManager cannot be constructed. You must configure the container to supply this value.

The frustrating thing is that the above code and configuration work perfectly fine when called from a console application. It's probably important to note that I've also had to copy several of the Enterprise Library DLLs into the powershell install folder under %SystemRoot%\system32\WindowsPowerShell\v1.0\ to resolve some other errors when using the cmdlet. I've also needed to set the working directory in powershell using the command[System.IO.Directory]::SetCurrentDirectory("ProjectDirectoyr\Widgit.EnterpriseLibraryCmdlet\Widgit.EnterpriseLibraryCmdlet\bin\Debug") to make sure that the config file is read. I'm not really sure what I'm missing at this point, so if anyone has any ideas or pointers, I'm all ears.

Jun 2, 2011 at 11:57 PM

Ok, so I've partially solved my issue. I removed the command to set the current working directory from my powershell startup script, and then copied my config file to %systemroot&/system32, and it worked.

I'd really like to be able to install and run this cmdlet without having to resort to copying files to System folders though.

Jun 3, 2011 at 7:06 AM


I haven't personally tried with Powershell Cmdlets and how it actually works but I assume you declare your FileConfigurationSource inside your executable project and the Widgit.EnterpriseLibraryCmdlet.dll.config is found on the same location as your exe. I guess that the exe is created in %systemroot&/system32?


Noel Angelo Bolasoc
Global Technologies and Solutions
Avanade, Inc.

Jun 3, 2011 at 5:52 PM

The exe in my case is the powershell executable; custom cmdlets are compiled into class libraries, and then have to be loaded by powershell, so I don't have too much leeway there. I've been looking into the issue more, and I think I may have to fiddle around with app domains.