Thursday, July 10, 2008

WCF in .NET 3.5 SP1 and Enterprise Library - TypeInitializationException

I have been fighting a maddening issue. It seems that if you have a WCF service under the .NET 3.5 SP1 beta that is impersonating the caller--either using the ServiceModel pipeline or ASP.NET Compatibility Mode--calls to Enterprise Library assemblies (at least for logging or data access needs) will fail with the following exception:
"The type initializer for 'Microsoft.Practices.EnterpriseLibrary.Logging.LogEntry' threw an exception."
When you dig for the inner exception, you find:
Could not load file or assembly 'System.Management, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Access is denied.
I've tried numerous things to get around this, such as:
  • Changing the application pool identity to Local System
  • Directly referencing System.Management in the service assembly
  • Adding System.Management (and the Ent Lib assemblies, for that matter) to the <assemblies> node in the web.config
** Update - 11 Jul 2008: Client configuration changes were required to correct the problem. In the client's app.config, configure a behavior for the endpoint to allow impersonation:
<client>
<endpoint address="http://server/WcfService1/Service1.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IService1"
contract="ServiceReference2.IService1" name="BasicHttpBinding_IService1"
behaviorConfiguration="endpointBehavior"/>
</client>
<behaviors>
<endpointBehaviors>
<behavior name="endpointBehavior">
<clientCredentials>
<windows allowedImpersonationLevel="Impersonation"/>
</clientCredentials>
</behavior>
</endpointBehaviors>
</behaviors>
Then, for some reason, an IIS reset was needed to make the client start working. This article describes the problem in detail.

Here's the thread over on the Enterprise Library forums where I was corresponding about the issue.

No comments:

Post a Comment