Finding what the real error is can sometimes be a bit tricky since the real error actually is embedded a bit down the exception hierachy. For instance, I recieved the following error when trying to send an email with the normal .NET mail classes using a workflow-dll.
Error code=8004280b. Unable to access the object CDO.Message.
I started thinking that there might be some different version between my local .NET and the server on where the program was run. I also thought there might be some problem with finding/accessing the dll. A bit weird but it had to be something.
However, after searching the internet I found that this error might not actually be the real error. Try recursing down into the exceptions to find the real error, and I did. With the following code:
catch(Exception ex )
OutText(“The following exception occurred: ” + ex.ToString() ); //check the InnerException while( ex.InnerException != null )
OutText(“The following InnerException reported: ” + ex.InnerException.ToString() ); ex = ex.InnerException;
The output made me solve the problem in 5 sec, I had forgot to assign a to-adress in the mail. A weird error message for a simple and stupid error. So, from now on, I am always a bit sceptical on what error is shown and if it is the real error or not.
CRM and SharePoint Consultant