Exception handling when working with the CRM Web Services

Source (by Mitch Milam)

I just ran into something that I have never seen before related to a SoapException:

I was updating my Export JavaScript utility when I received an error message that was blank.  Very odd, I thought.  After a bit of digging, I found the error:

Server was unable to process request.
—> Exception has been thrown by the target of an invocation.
—> The type initializer for ‘Microsoft.Crm.WebServices.CrmAuthenticationSoapExtensionBase’ threw an exception.
—> The server is not operational.

Now at this point, I really don’t know what happened, but my development CRM 4.0 server was in some type of non-functional state that required me to perform an IISRESET to recover from.  That is not the interesting thing here today.

The interesting thing is where the error message was found.  Here is an example the code that normally use to detect an error when using the CRM Web Service:

catch (SoapException ex)
{
    MessageBox.Show(ex.Detail.InnerText,
                    Properties.Resources.MSG_AN_ERROR_HAS_OCCURRED,
                    MessageBoxButtons.OK,
                    MessageBoxIcon.Error);
}

Usually, the actual error message is found in the SoapException.Detail property and you can access it via the InnerText or InnerXml properties, depending on how you wish to handle it.

Today, the error message was actually in the SoapException.Message property, which I find very odd.  As I said, I’ve never seen this before so I don’t know what happened, but in order to prevent a blank error message from appearing to the user, I created the following work around:

catch (SoapException ex)
{
    string errorMessage = ex.Detail.InnerText;

    if (string.IsNullOrEmpty(errorMessage))
    {
        errorMessage = ex.Message;
    }

    MessageBox.Show(errorMessage,
                    Properties.Resources.MSG_AN_ERROR_HAS_OCCURRED,
                    MessageBoxButtons.OK,
                    MessageBoxIcon.Error);
}

As you can see, I just take into account the possibility that the Detail.InnerText property is blank and if so, just use the standard Message property to be safe.

My note –

Requirements

Namespace: System.Windows.Forms

Platforms: Windows 98, Windows NT 4.0, Windows Millennium Edition, Windows 2000, Windows XP Home Edition, Windows XP Professional, Windows Server 2003 family, .NET Compact Framework

Assembly: System.Windows.Forms (in System.Windows.Forms.dll)

2. Another post (config.isv)

Troubleshooting Dynamics CRM extensions – Part 1

Posted by: Gayan Perera

Friday, 6 August 2010

In this multi-part blog series I’ll show you how you can troubleshoot errors in Dynamics CRM. Part 1 will cover ISV extensions (custom aspx pages); Part 2 will cover plugins, part 3 and 4 let’s see how we go ☺

We specialise in creating xRM solutions and most of them are fairly large involving custom aspx page extensions. Occasionally one of those pages will crash due to a bug, when this happens in the development environment we can catch and fix easily but when it happens in the production environment we need to have useful information about the crash in order to fix it.

One of the techniques is making sure we are notified whenever there is an unexpected crash. We do this by using an HttpModule and registering it inside the web.config file.

<add name=”ErrorModule” type=”Magnetism.Generic.ErrorModule, Magnetism.Generic” />

We capture the following information

• Error using Server.GetLastError();

• Form keys and values using Request.Form.Keys

• Server variables using Request.ServerVariables

• Session keys and values using Session.Keys

All of that information gets emailed to <spam-blocker>@magnetism.co.nz.

Stack trace, form variables and session variables gives us an insight into the problem and gives us a starting point.

The added benefit of having the error emailed to us is when the user submits a bug report with unuseful information all we need is the approximate time it happened and we can look at where and why it happened.

Another technique we use is tracing within the application, we write all important events to a log file, which can be turned on or off via the web.config file, this allows us to track down logic errors in the production environments where debugging is not available.

When dealing with calculations in addition to unit tests a tracer is used in the production environment to track anomalies.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: