Archive for the ‘Microsoft Enterprise Library’ Category

Enterprise Library ExceptionManager.Current Throws ‘Exception Thrown By Target Of Invocation’ After Renaming Namespace

December 14, 2011

The problem, dear Tadpolers, is that the ExceptionManager cannot load because the type of the Exception no longer exists because the namespace that it originally lived in has just been renamed. Therefore the ExceptionManager cannot load its handlers.

In my case I had a ReplaceHandler:
add name="Replace Handler" type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ReplaceHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" exceptionMessage="Data Access Error. Please notify Service Desk." exceptionMessageResourceType="" replaceExceptionType="Common.RepositoryException, Common, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"

But then I renamed The Namespace ‘Common’ to Norbert.Common, so the next time the ExceptionManager tried to load its ReplaceHandler it could not find the namespace Common or the type Common.RepositoryException, so its threw a TargetInvocationException.
I had to go through my app.config and update all instances of Common.RepositoryException to Norbert.RepositoryException like so:

add name="Replace Handler" type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ReplaceHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" exceptionMessage="Data Access Error. Please notify Service Desk." exceptionMessageResourceType="" replaceExceptionType="Norbert.Common.RepositoryException, Common, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"

Sweet As..

System.Configuration.ConfigurationErrorsException The Process Was Terminated Due To An Unhandled Exception.

September 26, 2011

We were getting these error in our UAT environment, but not DEV. Betcha you are too.

The reason for this error is that your Config file does not have the structure expected by the .NET runtime. This means that the app. crashes when the Configuration File is accessed.

The particular way in which our config file was malformed was that we were missing the Oracle.DataAccess.Client Section within system.data which was expected because the runtime was trying to load that section due to the presence of a DbProviderConfigurationHandler.

That DbProviderConfigurationHandler was being invoked because we are using Entity Framework connecting to an Oracle Database. EntityFramework was attempting to load various Oracle bits and pieces because the connection string in the app.config within the Visual Studio Class Library Project that connected to the database (i.e. our DAO project) was attempting to load the Oracle DataAccess Provider. This invoked the DbProviderConfigurationHandler but the relevant section in the app.config was not present.

Later on when we manually added the Oracle.DataAccess.Client section we got a crash because the tester’s machine did not have a full installation of Oracle Client for Entity Framework. That’s this sucker.

Now, solving this this was an enormous relief to us because that MinDate setting was being used to dynamically populate an Infragistics ValueConstraint control. When app.config was accessed that control would throw a humungous StaticMarkup Exception. Now this made sense because the ValueConstraint was being populated through a WPF Style but fooled us into thinking that somehow our tester’s machine (running XP) were incompatible with the Infragistics ValueConstraint control. Our DEV machines (running Windows 7) were all fine with the ValueConstraint control.

When we took the ValueConstraint control out (by commenting out the Style) the tester’s machine loaded a cut-down version of our app. fine, but that was only because the cut-down app no longer accessed app.config. Nothing to do with the actual ValueConstraint control at all.

After we removed the ValueConstraints we no longer got StaticMarkup Exception but we did get ConfigurationErrorException and that led us on a Phase 2 Journey Of Pain that, via Divide and Conquer, finally showed us that loading EntityFramework was the REAL real issue.

But not now.

Gloat.

So, bottom line: check that all the Sections expected by your Section Handlers are present. Go back to machine config and see what’s being loaded there and make sure everthing you are expecting to be installed is really installed.

EnterpriseLibrary ExceptionHandlingBlock EventLog Not Written

September 22, 2011

This is a bit of a newb ‘have you tied your shoelaces together’ kind of post, but since I fit the aforementioned category… what the heck…

Yeah, so my EventLogs were getting written, then later on they weren’t getting written, so what changed ?

Well I sat down and picked carefully through my app.config using the Enterprise Library Configuration Tool trying to see whether or not all the bits were connected properly. And what I think I saw was that the Logging Category of my Logging Exception Handler was set to ‘General’ but that under ‘Logging Settings’ the ‘General’ category did not have the Event Log Trace Listener added to it.

So I added ‘EventLogTraceListener’ to ‘General’ and simultaneously removed it from another category,’Logging Errors And Warnings’.

Except nothing happened…still no EventLog.

Except that when I closed my hosting app again and reopened the Configuration manager again and generally opened and closed the car doors in a futile attempt to make something change… it suddenly worked.

So Partial Huzzah (PHUZ)!. Nah, bugger it: HUZZAH!

That feels better.