A world apart from the everday ...

Bizarre errors... [fatal error X1001: unknown system exception]

In an earlier post (here) I discussed a truly bizarre error received when trying to compile an orchestration. Well at least on that occasion it gave me SOME information, it might've been cryptic but at least I has somewhere to start chasing the ghost ...

Today I got what must rank as the most obscure and useless error message I have ever received during BizTalk development, or any development for that matter.

Let me explain ...

See if you can spot what caused the exception before getting to my explanation of it. Once you see the explanation it's like Doh! [done in best Holmer Simpson voice]

So I've been working on this "little" orchestration for some time now which is exposed as a web service indirectly through it's schemas, as per accepted best practices for exposing web services. No biggie there.

I've also defined a standard Service Response message that my services return which looks a little like this:

<ServiceResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <MessageDateTime>2001-12-17T09:30:47.0Z</MessageDateTime>
   <Error>true</Error>
   <Messages>
     <Message>Some error message goes here</Message>
     <Message>Some other message</Message>
   </Messages>
</ServiceResponse>

Great,

So then I proceeded to build a simple helper class in .NET so I could build up one of these beauties dynamically inside my orchestration. This helper class looked like this:

For brevity I've removed the fluff and only left stuff that is applicable to this post

namespace MessageHelpers
{
    public partial class ServiceResponse
    {
        private System.DateTime messageDateTimeField;
        private bool errorField;
        private ServiceResponseMessageList messagesField = new ServiceResponseMessageList();

        [XmlArrayItem(ElementName = "Message", IsNullable=true)]
        public ServiceResponseMessageList Messages
        {
            get { return this.messagesField; }
            set { this.messagesField = value; }
        }

        public XmlDocument ToXmlDocument()
        {
            XmlDocument doc = new XmlDocument();

            XmlSerializer serializer = new XmlSerializer(typeof(ServiceResponse));
            StringBuilder sb = new StringBuilder();
            serializer.Serialize(new StringWriter(sb, CultureInfo.InvariantCulture), this);
            doc.LoadXml(sb.ToString());

            return doc;
        }
    }

    public class ServiceResponseMessageList : IList<string>
    {
        public override string ToString()
        {
            StringBuilder builder = new StringBuilder();
            foreach (string item in this)
            {
                builder.AppendLine(item);
            }

            return builder.ToString();
        }
    }
}

So this is simple enough ...

Wrote my tests, tested it and it all worked really nicely.

I then added a local variable to my orchestration of type ServiceResponseMessageList with the intention of doing something like shown below in a message assignment shape to build up my response message

Happiness ... or so I thought.

I hit Ctrl + B and Visual Studio cranked away for ages and eventually threw the following:

------ Build started: Project: AMH.Integration.Integer.BizTalk.Orchestrations, Configuration: Deployment .NET ------
Updating references...
Performing main compilation...
fatal error X1001: unknown system exception

There's the beauty in all it's glory!

fatal error X1001

Unkown system exception

Man Alive!

Have you spotted it yet? It's actually quite obvious, once you know where to look.

Got it? Given up?

Well we all know that BizTalk 2006 doesn't know about System.Collections.Generics right ...

Ok there's a massive hint

The ServiceResponseMessageList class inherits from a List<string>. Hmmm. Doh!

Adding a variable of this type to my orchestration is what caused this subtle piece of brilliance to appear.

Look, I know it was my fault entirely for writing ridiculous code, but why oh why can we not have decent, descriptive and informative error messages ? Is this too much to ask ?

A decent descriptive error message along the lines of

"adding a variable of type X that inherits from System.Collections.Generics is not supported"

would've saved me a few hours of ripping out my non-existent hair!

BizTalk User Group ... next meet ....

Beware of bizarre errors for "unreachable code detected" inside an orchestration

If you've done any work with BizTalk orchestrations you've had to construct a message inside an orchestration somewhere ...

There are a couple of ways of achieving this as detailed here by Matt Meleski.

Briefly you can do the following inside an Expression shape or an orchestration

xmlDoc = new System.Xml.XmlDocument();

xmlDoc.LoadXml("<ns0:SomeMessage></ns0:SomeMessage>");

msg_SomeMessage = xmlDoc;

Drop this little bit of magic into a Message Assignment shape and presto, you're ready to go with a blank message of whatever you wish.

No worries there, I've done that a million times if I've done it once, never had any hassles ... until today that is!

I did a similar thing today, except with Xml a little more complex than the trivial example above ... but when attempting to build the orchestration this time I got the following cryptic error message

Cannot implicitly convert type 'System.Xml.XmlDocument' to 'Microsoft.XLANGs.RuntimeTypes.XmlDocumentSerializationProxy'. An explicit conversion exists (are you missing a cast?)

WHAT?

I tried Googl'ing this beauty ... and nudda. Nothing. Oh joy ... now what?

Heck I tried hundreds of different things. Nothing wanted to work. It all looked good to me, but yet for some reason the orchestration just did not want to build.

In my desperate attempt to figure out what was going on I scanned through the build output window, nothing much odd going on in there either except for a small warning hiding away ...

warning X4003: unreachable code detected

Well now ... what have we here?

Seems I had a branch of a decision shape that would never be hit. Well ok, so what? Right?

WRONG!

The problem with this branch was that my Construct message shape was sitting INSIDE this branch. <the reason why this branch was unreachable is worth another post on it's own ...>

No ways ....

I moved the same construct shape to outside of this branch and the orchestration builds fine.

So I fixed the actual cause of the exception, the warning above, by removing the "unreachable" branch of the decision shape; and presto ... my orchestration compiles and all is well once again in my world.

Nice useful exception message there Microsoft, thanks for that!

*sighs*

There goes another hour or three of wasted time; try explain that to your project manager.

Dialing under the influence ....

So how many times have you done it? Come on admit it ... we've all done it at least once. Some of us just can't help ourselves ... it's an addiction.

What am I talking about?

Well picture this .... You go out for a drink or two, or three, or four (you know how it goes). At some point during the evening when you're barely able to construct a sentence consisting of little more than a few slurrs you feel this strange weight in your pocket. Why, it's your cellphone, here's a smashing idea ... lemme text my insane ex that I have not spoken to in 10 years since she chased me out of the house wielding a sharp knife!

Or at round about the same time of the evening you think it a marvelous idea to text your boss telling him to take his job and stuff it where the sun don't shine.

Sound familiar? How many of you did this very thing this year on new year's eve?

Well thankfully if you live in Auz and use Virgin Mobile as your provider there is a solution to this silly bizarre derranged act of madness ....

http://www.virginmobile.com.au/dui/

Thank goodness for that. I recon the 333CLEAR would be added to many speed dials! My only question is, what if in your alcohol induced state of slumber you miss the 6am window .... hmmmm.

So come on Vodacome / MTN / Cell C ... how about the same thing here please? Or do you guys make that much off DUI calls that you're scared you lose the revenue?

So now you know you're not alone and remember .... Don't DUI!