So, your application is crashing and it is crashing in?the?bad way. After spending hours of debugging and trying different things you figured out that this is this Xslt stylesheet that causes all the problems. How come? XslCompiledTransform is a compiler. It’s a bit different from C# or VB.NET compilers because it runs at runtime but the result of the compilation is basically the same – IL (Intermediate Language) code. One of disadvantages of running compilation at runtime is that compilation issues may have impact on the running application. In the “offline” scenario compiler would just return an error (the one I hate the most is “Internal Compiler Error” – still it will not affect my app at runtime ?? at worst there is no app). So, compilation may be one source of problems. The other source of problems can be the IL code the stylesheet was compiled to. Here there is not much difference between code generated from Xslt, C# or VB. In any case it is easy to write a program that compiles correctly but misbehaves at runtime (bugs anyone?). Let’s take a look at two most common unexpected exceptions you may hit when working with XslCompiledTransform and ways to resolve them.
Xml is ubiquitous. No doubt about it. It is being used almost everywhere and almost by everyone. This includes places where huge amounts of data are being processed. This means xml files (or streams) used there are also huge. And the bigger the Xml file the harder it is to process. The two biggest problems are:
You need to query the document with a couple of XPath expressions or transform it with an Xslt file but the document is too big to be even loaded (the rule of thumb is that an Xml document needs up to 5 times memory of its size on the disk). When you try to load the document you get OutOfMemoryException and that’s about where your Xml processing ends.
You are able to load the document but all the queries or transformations are sloooow (and I assume it’s not because the queries or Xslt stylesheets are poorly written – if you are not sure see Effective Xml Part 3)
“Really?”
“Yeah, XslCompiledTransform is fast… if used correctly.”
Indeed, depending on how you use XslCompiledTransform API your transformations can be really fast or not-that-fast (to say the least). The key to understanding where this difference comes from is to understan what XslCompiledTransform.Load() method actually does. The name of the method indicates that it is just used to load Xslt stylesheets. In reality the method does much more than this. It not only loads the Xslt stylesheet but it also compiles it to IL (Intermediate Language). Yes, after the stylesheet has been “loaded” somewhere there in memory is the real code built based on the provided stylesheet. Generating this code (i.e. “loading” the stylesheet) is costly but it allows for fast transformations – when you start a transformation in your app it no longer deals with the stylesheet, it just invokes the code the Xslt stylesheet was compiled to.
XPath expressions are pretty flexible. This flexibility allows for very creative ways of using XPath. Unfortunately some of them are suboptimal and cause bad performance of apps. This is especially visible in Xslt transformations where stylesheets contains tens if not hundreds of XPath expressions. Here is the list of the most common bad practices (or even anti-patterns) I have seen:
LINQ to XML 是一种启用了 LINQ 的内存 XML 编程接口，使用它，可以在 .NET Framework 编程语言中处理 XML。
LINQ to XML 将 XML 文档置于内存中，这一点很像文档对象模型 (DOM)。?您可以查询和修改 XML 文档，修改之后，可以将其另存为文件，也可以将其序列化然后通过 Internet 发送。?但是，LINQ to XML 与 DOM 不同：它提供一种新的对象模型，这是一种更轻量的模型，使用也更方便，这种模型利用了 Visual C# 2008 在语言方面的改进。
LINQ to XML 最重要的优势是它与 语言集成查询 (LINQ) 的集成。?由于实现了这一集成，因此，可以对内存 XML 文档编写查询，以检索元素和属性的集合。?LINQ to XML 的查询功能在功能上（尽管不是在语法上）与 XPath 和 XQuery 具有可比性。?Visual C# 2008 集成 LINQ 后，可提供更强的类型化功能、编译时检查和改进的调试器支持。
LINQ to XML 的另一个优势是通过将查询结果用作?XElement?和?XAttribute?对象构造函数的参数，实现了一种功能强大的创建 XML 树的方法。?这种方法称为“函数构造”，利用这种方法，开发人员可以方便地将 XML 树从一种形状转换为另一种形状。继续阅读LINQ TO XML 笔记
