BizTalk 2004 to 2006 Upgrade XSLT issue

I have been working on a BizTalk 2004 to 2006 upgrade and encountered an interesting issue when testing. It was an XLANG error with the relevant part of the error message log being:


Unable to cast object of type 'MS.Internal.Xml.Cache.XPathDocumentNavigator' to type 'System.Xml.IHasXmlNode'


The reason for this is that in one of the XSLT maps there was some custom c# code that made a cast. The cast involved the XPathDocumentNavigator class from the System.Xml.XPath namespace. The XSLT engine loaded the version in MS.Internal.Xml.Cache first.

To fix this issue I just made sure the references to XPathDocumentNavigator were fully qualified.

The lesson learned was that it always pays to fully qualify your references to classes in embedded .net code in XSLT.

xsd Command line tool for Visual Studio

There is a perhaps quite underutilized command line tool available for Visual Studio. It is called xsd.exe and is installed in most typical configurations of Visual Studio 2005 (and 2003 for that matter). To use it, simply open a Visual Studio 2005 Command Prompt window (from the Visual Studio -> Visual Studio Tools folder in the start menu). Alternatively you can open the folder C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin substituting your custom install path if necessary.

It is capable of a number of quite useful operations including:

1) The ability to generate XSD schema files from XML files. The syntax for that is simply:
xsd %1
Where %1 is the name of the xml file. This will generate an xsd with the same filename as the xml except with an xsd extension.

2) You can generate sub classed datasets via this method:
xsd %1 /d
Where %1 is the xsd file. This will output similary named class files that provide custom datasets based on the schema provided. The smart bit about this is that hidden primary and foreign keys are added to the dataset transparently. The reason why this is so smart is that is provides a means for you to programatically link nested elements to parent elements. When a typical command like:
MyDataSet.WriteXML(@"c:\out.xml"); or
MyDataSet.GetXML();
the Xml generated adheres to the schema provided during your xsd output. For some of you this may be pretty straight forward but I know some, including myself, who it took a while to figure out how this all fits together.

3) You can also generate classes for the objects, which is probably less useful, but handy for those wanting assistance to quickly create business objects for large schemas. The way to do this is:
xsd %1 /c
The %1 parameter being the xsd schema file.

4) Another useful operation for this command line utility is the ability to convert xdr to xsd. This can sometimes save a lot of effort! To do this:
xsd %1
The parameter %1 being the name of the xdr file (which must have an .xdr extension!).

Note that by default the classes (and dataset classes) that are generated output as c #. You can alter which language these output in by using the /language (or /l) switch. The possibilities are CS (C#), VB, JS, VJS or CPP. You can also instead "provide a name for a fully qualified class implementing System.CodeDom.Compiler.CodeDomProvider". This will let you output in your favourite niche langauge (anyone for IronPython or perhaps even f#?).

There are a bunch of other cool things this utility can achieve but I shall leave the exploration to you.

Catastrophic Error, Multiple Infopath Forms

An error that seems to be plaguing a number of people occurs during the following scenario:

A user attempts to open a new instance of InfoPath, loading a form that is based on a template that there is already a form open form. When the form attempts to load InfoPath spits back a helpful error: "Catastrophic failure!".

A workaround for this, which I am not convinced is the best solution, is to remove the name attribute from the processing instructions.

So typically you may have a PPI that looks like this:


<?mso-infoPathSolution solutionVersion="1.0.0.562" productVersion="11.0.6565" PIVersion="1.0.0.0" href="file:///\\yourhost\templates\yourTemplate.xsn" name="urn:schemas-microsoft-com:office:infopath:yourTemplate:-myXSD-2006-06-12T01-41-41" ?><?mso-application progid="InfoPath.Document"?>

Change this to:
<?mso-infoPathSolution solutionVersion="1.0.0.562" productVersion="11.0.6565" PIVersion="1.0.0.0" href="file:///\\yourhost\templates\yourTemplate.xsn" ?><?mso-application progid="InfoPath.Document"?>

This will do the trick it seems.