In some recent deployments for
different clients, I've had problems with the
XsltListViewWebPart when custom XSL is used, specifically when the custom XSL is
deployed to the server and the XslLink property of the Web Part is used.
There's a couple of specific problems that I've encountered and I thought it useful to blog about their symptoms to help anyone else that might have similar issues.
One of the problems I've seen is based on a significant performance degradation (see this post: http://blog.vossers.com/2012/01/28/how-the-xsltlistviewwebpart-in-sharepoint-2010-can-be-a-real-performance-killer/). If there are multiple XsltListViewWebParts on a page that employ custom XSL using the XslLink property of the web part then this issue might show up. It appears that the way the XSL on the server is cached, especially on load-balanced environments, can cause a problem if the timestamps are different, i.e. the files deployed at different times. Microsoft appear to have issued a HotFix to resolve some of this problem, but based on the blog post I link to above, I don't think that this will always fix everything. The way the XSL is cached by SharePoint appears to have an issue and can randomly drop all the compiled XSL and attempt to re-compile, using a single thread. In a page with multiple XsltListViewWebParts you can see why this might cause random performance degradation issues. One of the suggested work-arounds is to place the XSL using the XSL web part property, instead of XslLink. I'll come back to this in a moment.
The second problem has recently come to light. I had a deployment that put XSL onto the server. However, I had several XsltListViewWebParts on a page using several different custom XSL files all set up to be used via the XslLink property. Internally it all worked fine, but when the files were deployed into the customer environment, older versions of the XSL files appeared to be used to generate the HTML, and not the newer versions. Without any action on our part, the problem resolved itself overnight. Later on that same day, the problem re-surfaced and the HTML generated was back to the old version. Later again, on the same day, the problem disappeared again without any interference from us.
Having reviewed the problem and found the following article (from October 2012) from Microsoft, I would suggest that any customisation of XSL for the XsltListViewWebPart is done using the XSL property of the web part, and not the XslLink property. In both scenarios, this appears to mitigate any potential problems, so from now on when I do these kinds of customisations, I will always adopt this approach: http://blogs.msdn.com/b/spses/archive/2012/10/23/guidance-for-xsllink-property-with-the-xsltlistviewwebpart.aspx
There's a couple of specific problems that I've encountered and I thought it useful to blog about their symptoms to help anyone else that might have similar issues.
One of the problems I've seen is based on a significant performance degradation (see this post: http://blog.vossers.com/2012/01/28/how-the-xsltlistviewwebpart-in-sharepoint-2010-can-be-a-real-performance-killer/). If there are multiple XsltListViewWebParts on a page that employ custom XSL using the XslLink property of the web part then this issue might show up. It appears that the way the XSL on the server is cached, especially on load-balanced environments, can cause a problem if the timestamps are different, i.e. the files deployed at different times. Microsoft appear to have issued a HotFix to resolve some of this problem, but based on the blog post I link to above, I don't think that this will always fix everything. The way the XSL is cached by SharePoint appears to have an issue and can randomly drop all the compiled XSL and attempt to re-compile, using a single thread. In a page with multiple XsltListViewWebParts you can see why this might cause random performance degradation issues. One of the suggested work-arounds is to place the XSL using the XSL web part property, instead of XslLink. I'll come back to this in a moment.
The second problem has recently come to light. I had a deployment that put XSL onto the server. However, I had several XsltListViewWebParts on a page using several different custom XSL files all set up to be used via the XslLink property. Internally it all worked fine, but when the files were deployed into the customer environment, older versions of the XSL files appeared to be used to generate the HTML, and not the newer versions. Without any action on our part, the problem resolved itself overnight. Later on that same day, the problem re-surfaced and the HTML generated was back to the old version. Later again, on the same day, the problem disappeared again without any interference from us.
Having reviewed the problem and found the following article (from October 2012) from Microsoft, I would suggest that any customisation of XSL for the XsltListViewWebPart is done using the XSL property of the web part, and not the XslLink property. In both scenarios, this appears to mitigate any potential problems, so from now on when I do these kinds of customisations, I will always adopt this approach: http://blogs.msdn.com/b/spses/archive/2012/10/23/guidance-for-xsllink-property-with-the-xsltlistviewwebpart.aspx
No comments:
Post a Comment