OK, thanks, we have reproduced the failure.

This is associated with byte code generation, so you can work around the problem by adding the API call

processor.SetProperty("http://saxon.sf.net/feature/generateByteCode", "false");

The reason the 3.0 streamable example works is that byte code generation is automatically switched off for streamable templates.

What's happening here, as far as we can tell, is that we are generating byte code corresponding to your XSLT stylesheet; we are then translating the byte code to IL code using IKVMC. The byte code that we generate is a class which inherits from the class com.saxonica.bytecode.map.CompiledContextMappingFunction, which is present in saxon9ee.dll. When we run from within the command line Transform command, which is in the same DLL, this is successfully loaded, but when we run from a different DLL, a failure occurs when attempting dynamic loading of the superclass.

One of the puzzles is how something so simple is failing when all our tests worked OK - but I suspect that observation won't help us in finding the cause and fixing it.

As we've reproduced the problem, we should be able to find a fix. My colleague O'Neil Delpratt will be working on this.


Michael Kay

On 19/03/2012 08:24, Aleksandrs Zeļikovičs wrote:

Thank you for your answer,


Before buying saxonica application for our product we test it with simplest XSLT.

We will have catalog with xslt (not only 3.0).


Interesting that under Console application all XSLT can be run.


Testing your product, this XSLT can’t be run Under windows project:


1.0 Exception in Compile:  com.saxonica.bytecode.map.CompiledContextMappingFunction

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" exclude-result-prefixes="xs">

       <xsl:output method="xml" encoding="UTF-8" indent="yes"/>

       <xsl:template match="/">


                     <xsl:for-each select="a/b">


                                  <xsl:value-of select="string(.)"/>