As we focused on having better monitoring and debugging of our applications and services, our team recently began researching an implementing the Application Logging Block feature of the Microsoft Enterprise Library 5.0. The lot fell to me as the one who would be the team SME (Subject Matter Expert)—essentially the one who researches a technology and provides insight and guidance to the rest of the team related to that technology. This post is one of what is likely to be a number of posts of things I have learned in researching and testing the Application Logging Block.

History aside, you are likely finding this post by way of a search for the error in the title, so I cut to the chase with one of the minor tripping points I have encountered to date—minor because it is easy to resolve, but not-so-minor in figuring it out in the first place. Pardon the formality of the following, but I figured a knowledge-base-article-like format would best serve in getting the information across as efficiently as possible.

As always, your comments are welcome.

-------------------------------------------------------------------------------------------------------------------------------------

System.TypeInitializationException from a Microsoft Enterprise Library Aware Application

Pre-Read Notes:

  • While the context of this blog post is Microsoft Enterprise Library 5.0, the same issue can occur in other versions of the library as well.
  • Italicized and angle-bracket-enclosed text below represents placeholders for context-specific values (such as a class name specific to your project) that would otherwise show.
  • I abbreviate “Microsoft Enterprise Library” to MEL throughout.

Problem Summary:

You encounter an exception similar to the following when running an application that you have created utilizing one or more MEL assemblies (e.g. in support of an application block).

System.TypeInitializationException

Exception Message=The type initializer for '<class>' threw an exception.

Inner Exception Message=An error occurred creating the configuration section handler for loggingConfiguration: Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) (<source file location> line <line number>)

Root Cause:

You have built your application using references to signed MEL assemblies but the current configuration or execution context is resulting in unsigned assemblies being referenced.

Resolution:

Ensure that the resulting application references and has access to the signed assemblies wherever it may be run. This can be accomplished in a number of ways, such as:

  • Setting the Copy Local property on each MEL assembly reference to True.
  • Reference a commonly-accessible path to the signed assemblies rather than using those found in the GAC (such as you get from installing MEL).
  • Ensure that MEL is installed on the final target location(s) of your application or service

If you have a dependency on the unsigned assemblies (those that are installed with the MEL source files) then be sure in your project(s) to reference the unsigned instance(s) of the assembly(-ies) from the outset, especially prior to first modifying the app.config file with the Enterprise
Library Configuration Editor. If you requirements change from using the signed assemblies to the unsigned assemblies (as could be the case when you decide mid-project to extend a MEL feature) an after-the-fact solution is provided in the More Information section below.

More Information:

Our team uses Microsoft Visual Studio for development and Microsoft Team Foundation Server for source control and remote builds. In my particular situation, I had referred to the signed assemblies in the GAC when creating my application (simply picking them from the list of available assemblies in the “Add Reference to…” dialog box in Visual Studio. Prior to submitting the build to the build server (which does not have MEL installed), I changed these references to point to a shared location in our source tree for such assemblies—not realizing that the assemblies located there were the unsigned versions.

Following that, when I tried to run the application off-box or when updating the app.config file with the Enterprise Library Configuration Editor I received the above exception.

As outlined above, there are various solutions to this issue when known in advance of creating your application. If, however, your application needs change mid-stream from referencing the signed assemblies to referencing the unsigned assemblies, the simplest after-the-fact solution I
have found is to modify the Enterprise Library 5 Assembly Set property of your solution, setting it to EntLibV5Src from the default (machine default). You need to reload your solution and change the related PublicKeyToken attribute to null from the actual public key token in your app.config before re-opening it in the Enterprise Library Configuration tool.

Additional References:

See also the following, which is related to MEL 3.0 but is still relevant for-the-most-part to MEL 5.0:

http://blogs.msdn.com/b/tomholl/archive/2007/04/19/avoiding-configuration-pitfalls-with-incompatible-copies-of-enterprise-library.aspx