saxon_home being ignored with 9.3 .net versio


  • Anonymous

    Hi Michael,

    we build a simple .net class for a client that invokes a transformation and
    shows a MessageBox in case of an error.
    The class is loaded in a powershell script.

    In the class we add a reference to saxon9pe-api.dll and IKVM.OpenJDK.Core.dll.
    The saxon-license.lic is in the same folder as the referenced dlls the
    saxon_home environment variable is set as described by you:

    Please save the license file in the xxxx/bin directory containing the Saxon
    software, and set the SAXON_HOME environment variable to the parent directory

    Now if we use Saxon 9.2 the licence file is found using SAXON_HOME, but when
    we try to invoke the transformation from within powershell we get a the
    following error: The type initializer for 'net.sf.saxon.Configuration' threw
    an exception.

    Which I guess was fixed in 9.3

    If we use Saxon 9.3 however SAXON_HOME seems to be completely ignored, the
    licence file is only found when it is in C:\Program
    However for the client the people managing the Server are not the same people
    who manage the application that will call saxon, so having a "portable" saxon
    that doesn't have to be installed to c: would be prefered.

    Also it is just us testing with PE, the client bought EE licences as far as I
    know, in case this makes any different.


  • Michael Kay
    Michael Kay

    I recently spotted that the instructions being sent out with new license keys
    needed updating, and this should have been done. You're right that SAXON_HOME
    is no longer relevant. On .NET in 9.3, Saxon should be installed using the
    supplied installation wizard. This creates a registry key, which identifies
    the location of the installed software. The license file should then be copied
    to the /bin subdirectory of this installation directory.

    We had a bug report recently from a user who found that this mechanism wasn't
    working on 64-bit systems because Windows aliases the registry entries (it
    maps the name you ask for to some other name, and this aliasing was kicking in
    when we write to the registry and not when we read from it). We've done a
    build that fixes this problem, which we can make available if needed - it
    wasn't publicly announced because we didn't run full regression tests on it,
    and were dependent on the customer to check that the fix actually works.


  • Anonymous

    Ok, so installing saxon using the installer is the only option to get the
    licensed saxon working, and a "portable installation" is not possible?
    This was actually my main issue.

    I don't have any issue using the installer on a 64bit System, so your build is
    not needed.

  • Michael Kay
    Michael Kay

    I'm not entirely sure what you mean by a "portable installation". You can of
    course choose where the installer does the installation. If you know what
    you're doing, you could also bypass the wizard and set the relevant registry
    keys yourself. Or (especially if you are installing Saxon as part of an
    application) you could fall back to one of the other mechanisms used by Saxon
    to locate the license file, for example setting the configuration property

  • tg

    Hi Michael,

    we cant install saxon via the wizard because our customer wants to copy the
    files manually without an installer. so thank you for the hint using the
    FeatureKeys.LICENSE_FILE_LOCATION property.

    well I tried to implement this but unfortunately it doesnt seem to work. here
    is the code I am using:

    processor.SetProperty("", licensefile);

    licensefile is a string with the location of the "saxon-license.lic" file in
    the filesystem. and It looks like saxon is finding it, because when we change
    the path in licensefile to a wrong location - an exception is thrown saying
    something like "cant find the license file". when the path is correct -
    nothing happens. so I guess he found it.

    but when we start a transformation using "next in chain" for example, the
    exception says that this feature is not supported with saxon HE...

    do you have a hint what I could do? Im a bit out of ideas right now :)


  • Michael Kay
    Michael Kay

    It looks as if you are running the transformation using the Saxon-HE code
    paths, despite the fact that you have activated Saxon-EE. I would need to see
    how you are running the transformation. There's something odd going on; it
    looks as if you have an EE configuration for loading the license file, and an
    HE configuration for running the transformation. Perhaps there is more than
    one Configuration object around.

  • tg

    Hi Michael,

    this is how we basically run the transformation:

    private bool work(string doc, string xsltfile, string target) {
                    Processor processor = new Processor(true);
                    processor.SetProperty("[url][/url]", Saxon_Home);
                    XdmNode input = processor.NewDocumentBuilder().Build(new Uri(doc));
                    XsltCompiler compiler = processor.NewXsltCompiler();
                    XsltTransformer xslttransformer = compiler.Compile(new Uri(xsltfile)).Load();
                    xslttransformer.InitialContextNode = input;
                    // Create a serializer                 
                    FileStream ziel = new FileStream(target, FileMode.Create, FileAccess.Write);
                    // Transform the source XML               
                    // Close the filestream

    In the references area of the project we linked (like my colleague already
    said) saxon9pe-api.dll and the IKVM.OpenJDK.Core. And we already tried that
    with the EE dlls. But with the same result.


  • tg

    the semicolon in

    processor.SetProperty("[url][/url]";, Saxon_Home);

    comes with the copy & paste.


  • Anonymous

    you could fall back to one of the other mechanisms used by Saxon to locate
    the license file, for example setting the configuration property

    What other methods are there to locate the license file that we could try.



  • Anonymous

    Hey Michael,

    is there any update on this? Did we find a bug here or is the error on our
    Sorry to press you, but we are aproaching a deadline with our client on this.

    Do you think there could be an issue with our liscence file?
    We are trying it with a PE liscence, our client recently bought 4 EE Site
    liscences if you think it would work with the EE I could try it with one of


  • Michael Kay
    Michael Kay

    Could I suggest you start by installing the maintenance release,
    using the installation wizard. This fixes the bug that was found in reading
    the registry on 64-bit systems. First try running something that needs a
    license from the command line; then try your application. If it doesn't work,
    please tell me exactly what you did and exactly what errors you got. The
    detailed error message is important even if it appears uninformative. Also
    please run with the -t option on the command line, or with the configuration
    "" set
    to "true" to maximize the diagnostics available; and either ensure that you
    capture the standard error output, if necessary by redirecting it to a file by
    setting the configuration property "
    " to the name
    of the file.

    It might also be useful to display the class name of the object returned by
    Processor.Implementation property, to check that you are in fact loading
    Saxon-PE or Saxon-EE software.

  • tg

    Hi Michael,

    as we said the main problem here is, that we need saxon to work without
    installing it via the wizard. however I downloaded and implemented
    its dlls into the project. Unfortunatly the result is the same.

    In the debugger when I look into the implementation property I see
    softwareEdition = "PE".

    This is what we get with time set to true:

    Failed unexpectedly: Failed to compile stylesheet. 1 error detected.Serialization parameter {{[url][/url]}next-in-...} is not available in Saxon-HE
    Tree size: 218721 nodes, 1215652 characters, 12541 attributes

    And this is what the standard error output says when saxon is installed with
    the wizard. The licence file is not in the bin directory in Program Files
    instead we referenced the licence file via the "
    " Property
    to a different location in the file system:

    Using parser org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser
    Found registry key at HKEY_LOCAL_MACHINE\Software\Wow6432Node\Saxonica\SaxonPE-N\Settings
    Software installation path: c:\Program Files\Saxonica\SaxonPE9.3N
    License file saxon-license.lic not found. Tried in file:/C:/Windows/assembly/GAC_MSIL/saxon9pe/, c:\Program Files\Saxonica\SaxonPE9.3N/bin/saxon-license.lic, c:\Program Files\Saxonica\SaxonPE9.3N/saxon-license.lic, classpath, . Running with licensable features disabled
    Building tree for file:///C:/Users/Tobias J. Goertz/Documents/Visual Studio 2010/Projects/XsltTransform/XsltTransformer/testfiles/in/P2000190.xml using class net.sf.saxon.tree.tiny.TinyBuilder
    Tree built in 234 milliseconds

    This is what the error looks like when we dont have Saxon installed and copied
    the files manually to a custom location. Also the licence-file is set here via
    "". This is what we actually need to achieve:

    Using parser org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser
    License file saxon-license.lic not found. Tried in file:/C:/Windows/assembly/GAC_MSIL/saxon9pe/, classpath, . Running with licensable features disabled
    Building tree for file:///C:/Users/Tobias J. Goertz/Documents/Visual Studio 2010/Projects/XsltTransform/XsltTransformer/testfiles/in/P2000190.xml using class net.sf.saxon.tree.tiny.TinyBuilder
    Tree built in 390 milliseconds

    When Saxon is installed via wizard, and the licence-file is put into its bin
    directory - everything works fine. But that not what we need in this case. We
    must be able to copy it where we want without registry settings. I guess that
    "" is ignored in some way.

    Thank you

  • Michael Kay
    Michael Kay

    I think that what is happening here is that the call to set the license file
    location successfully finds and reads the license file, but doesn't record the
    fact that it has done so in all the right places, which means that a
    subsequent request for license verification tries again to find the license
    using the registry key. In our testing this would have succeeded because the
    registry key happened to be set correctly. I'll attempt a fix. However, a
    cleaner workaround might be if you write a little script that sets the
    registry key to the required value.


  • Anonymous

    Hi Michael thanks for your answer,
    Software installation
    is the Registry Key we need to set right?

    If so I don't think we can do it because you can't write to HKEY_LOCAL_MACHINE
    as a normal User.

    Is there an equivalent path on HKEY_CURRENT_USER?

    On the clients server we don't have admin rights, that's why we can't use
    Saxon with the installer to begin with.



  • Anonymous
    2011-11-28 I guess not?