Saxon for .NET - exception.Encoding: windows-874 not found

MSXML currently supports only XSLT 1.0.
To benefit from XSLT 2.0 under .NET environment, you need some other XSLT processors.
For some reasons, I have chosen Saxon.
 
Saxon provides .NET developers with a number of objects to interact with XML and XSLT.
To use Saxon without installing to GAC, you need to have all of the following 5 files and make references to the 4 dll files:
 Magical Snap - 2008.06.23 16.31 - 001Magical Snap - 2008.06.23 16.35 - 002
** These dll files are based on Saxon-B 9.0 for .NET.
     They may be changed depending on Saxon's version (e.g. Saxon-B 9.1.0.1 - IKVM.GNU.Classpath.dll is changed to IKVM.OpenJDK.ClassLibrary.dll).
 
The following is a sample fragment of code for transforming XML: 
 
using Saxon.Api
...
 
using (TextReader sXsl = new StreamReader("myXslFile.xslt", Encoding.UTF8)) {
    Processor processor = new Processor();
    XsltCompiler compiler = processor.NewXsltCompiler();
    XsltTransformer transformer = compiler.Compile(sXsl).Load();
 
    XdmNode input = processor.NewDocumentBuilder().Build(xReader); // xReader is an XmlReader object containing XML content to be transformed.
    transformer.InitialContextNode = input;
 
    Serializer serializer = new Serializer();
    MemoryStream memStream = new MemoryStream();
    serializer.SetOutputStream(memStream);
 
    transformer.Run(serializer);
 
    memStream.Position = 0;
    string htmlString = string.Empty;
 
    using(StreamReader reader = new StreamReader(memStream)){
        htmlString = reader.ReadToEnd();
    }
}
 
However, running it yields "exception.Encoding: windows-874 not found" error.
This can be solved by adding the following configuration in web.config:
 
<configuration>
    <appSettings>
        <add value="utf8" key="ikvm:file.encoding" />
    </appSettings>
</configuration>
 
The page (with XSLT 2.0) is now rendered properly.
 
Saxon-B is open-source.
Saxon-SA is a commercial product.
Bookmark and Share

XslCompiledTransform vs. XslTransform - The Performance!

Today I have come across a very nice article about the performance of the XslCompiledTransform (.NET 2.0) vs. XslTransform (Obsolete).
The auther, Anton Lapounov, explained very well how he tested and how to improve the performance.
In conclusion, the XslCompiledTransform takes longer to load but it is much faster when transforming.
This is due to the absence of a native image of System.Data.SqlXml, the assembly where XslCompiledTransform resides, and thus JIT compilation is needed for the first run.
Anton solved this performance issue by NGen-ing it and that significantly reduces the XslCompiledTransform's load time (as well as that of XslTransform's).
 
Please feel free to visit his blog at XslCompiledTransform Slower than XslTransform?
Bookmark and Share

DNN on the Plesk!

The company I am working for has decided to host a website on a hosting with Plesk control panel.
For most websites, without pointing our DNS to this new IP, we can preview the site we create via the plesk sitepreview.
Our website is DotNetNuke-based.
To install DNN on the host, we copied the DNN website downloaded from www.dotnetnuke.com and put it under httpdocs/DotNetNuke directory (accessed via ftp).
We then created a virtual directory with the same name i.e. DotNetNuke and created a database to hold its data.
The connection string can be obtained via the control panel or you can contact the customer service for further assistance if you cannot find it.
To start configuring DNN, we then access the site via sitepreview expecting to see the DNN Wizard start page.However, DotNetNuke doesn't seem to like the sitepreview feature.Whenever we try to access the sitepreview, it redirects us to Godaddy's parking site (we host our domain with Godaddy).
Now what?If we can't access the site, how can we start setting up the DNN?This problem doesn't occur on a local machine since we can access the site directly (not via the Plesk sitepreview).After a few chats with the customer service, we realized that there is a way to fake our machines out to point to the live site IP address without having to go through the sitepreview.Yes! Modifying the hosts file is the solution.
Go to C:\WINDOWS\system32\drivers\etc (I presume that we have installed WINDOWS on c: drive). Or you can type %SYSTEMROOT%\system32\drivers\etc instead. Look for the hosts file named "hosts" (without any extension). Open it in your favorite text editor e.g. Notepad. Add the following lines after 127.0.0.1 line. --> This is why it accesses localhost when we type 127.0.0.1 as a url in the browser.
Please note that our domain is marathonsys.com.
207.176.157.19    marathonsys.com Save it and restart your browser (if opened). Now every time you enter www.marathonsys.com or marathonsys.com in your browser, it will access 207.176.157.19. To access our DNN web site, use http://www.marathonsys.com/dotnetnuke or http://marathonsys.com/dotnetnuke for the url.
 
This is normally used to test our websites on a test server.
But it can also be used in this case :)
 
These settings may need to be removed after we point the DNS to this host. We can either remove the lines or just comment them out by putting a sharp sign (#) at the beginning of the lines as we can see at the beginning of the hosts file that they used it to put some comments in the hosts file.
 
I hope this helps anyone working with DotNetNuke on the Plesk.
Bookmark and Share