1. Problem:
I encountered a problem difficult to diagnose related to deploying a BizTalk Server 2006 application and a functoid that have been compiled together but then deployed with different versions.
For example, let’s say you have developed and compiled a BizTalk application “A” version 1 using a functoid “F” version 1. Later on, you change some of the code inside the functoid and so you have a new version of the functoid, let’s call it functoid “F” version 2.
Note that by version 1 and 2, I do not mean the assembly version number; it is just a nomenclature I use to differentiate the versions. In my case, the assembly’s version number is fixed.
I often deploy new versions of functoids without having to recompile neither redeploy the BizTalk application but this time, the following error message appeared:
Microsoft.XLANGs.Core.XTransformationFailureException: Error encountered while executing the transform XXXX. Error:Unable to create the transform.. —> System.ArgumentNullException: Value cannot be null.
Parameter name: extension
at System.Xml.Xsl.XsltArgumentList.AddExtensionObject(String namespaceUri, Object extension)
at Microsoft.XLANGs.BaseTypes.TransformBase.get_TransformArgs()
at Microsoft.XLANGs.RuntimeTypes.TransformMetaData..ctor(Type transformBaseType)
at Microsoft.XLANGs.RuntimeTypes.TransformMetaData._creator(Type t)
at Microsoft.XLANGs.RuntimeTypes.MetadataCache._slowFor(Type t)
at Microsoft.XLANGs.RuntimeTypes.MetadataCache.For(Type t)
at Microsoft.XLANGs.RuntimeTypes.TransformMetaData.For(Type t)
at Microsoft.XLANGs.Core.Service.ApplyTransform(Type mapRef, Object[] outParams, Object[] inParams)
— End of inner exception stack trace —
at Microsoft.XLANGs.Core.Service.ApplyTransform(Type mapRef, Object[] outParams, Object[] inParams)
at Tourico.Tourico_SmartSearch.segment2(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)
2. Solution:
The message was not recorded in the Windows Event Log but as I catch and log exceptions in an exception handler; I could see the exception in my log.
As the message is rather vague, I spent quite a lot of time checking the maps and schemas used in the orchestration but found no clue.
I finally noticed that a functoid’s code had been changed and once I recompiled and re-deployed the BizTalk Application, everything worked fine!
I am not sure of the exact reason as normally you don’t need to redeploy the BizTalk application after having updated and GACed a functoid.
Anyway, if one day you encounter an error message of the same flavor, recompiling and redeploying the application might just work fine. Maybe this hint can help someone in the future 🙂
3. Note about exception handler in BizTalk Server 2006.
For the people who do not know, you just need to use a scope shape and its exception handler to have the equivalent of a try-catch block in a BizTalk orchestration. That gives you the opportunity to take action and/or log errors when exceptions are thrown from the orchestration.
To create an exception handler, drop a scope shape into your orchestration, right click on it and select “New Exception Handler”. Note that only scopes that are non-transactional or long running transactional can have an exception handler.
Here is how it looks like:
Everything in the first square (Scope_1) will be the “try” part and everything in the second square (CatchException_1) will be the “catch” part.