XslLink vs. <xsl:import> in Data View Web Parts (DVWPs)

2 minute read

With a title like that, should I even pretend that this blog is about anything other than SharePoint?

I had a nice Skypversation with Jeremy Thake (@jthake) earlier today.  (Yes, today’s posts do have a certain @jthake skew.) Jeremy was having a problem with SharePoint Designer, and was hoping that I could help.

What Jeremy was doing was perfectly good practice: he wanted to store his XSL for DVWPs in separate XSL files for better manageability and reuse. To do this, he was adding a link in the DVWPs using the XslLink tag, something like so:

<XslLink>Style Library/XSL Style Sheets/Marc.xsl</XslLink>

What was happening was that every time he was saving the page with the DVWP on it, the file in the XslLink was also being saved, and the variables were being replaced with hard-coded values.  This didn’t sound familiar to me until Jeremy shared his screen and showed me that this dialog was popping up:


Ths important trick here is to click the Set Action… button and tell SharePoint Designer not to overwrite the existing, supporting file:


SharePoint Designer is trying to be helpful, but sometimes it isn’t.  When it was saving the external XSL file (in my example, Marc.xsl), it was corrupting it by hardwiring some of the values.

So, problem solved for Jeremy, but the more valuable part of the conversation was, for me, the following part where we discussed the merits of using XslLink versus <xsl:import>. I’ve been in the habit of using <xsl:import>. (Take a look at my prior post on how it works: Unlocking the Mysteries of Data View Web Part XSL Tags – Part 20 – <xsl:import>.) Probably because of my aproaching things from the Middle Tier, I just had never considered XslLink.

As Jeremy and I talked this through, we decided that <xsl:import> may actually provide more flexibility.  One of the things that I like about it is that you can include any number of separate external XSL files which contain your XSL templates.  By keeping the templates separated into different files by functional groupings, you can mix and match the ones you need in any instance. For instance, I usually have one called Utilities.XSL which are just general purpose templates (things like StripHTML or GetUserID) and others for things like date arithmetic functions.  Then I’ll have the templates which are specific to what I am doing with a particular list or set of lists in another XSL file.  This lets me use to grab as few or as many of the templates as I need, while continuing to manage them in one central location.

Another pretty big plus is that I’ve never seen this corrupting hardwiring going on with . We decided that the approach probably wins the day over XslLink for these reasons.  What do you think?


  1. Marc, great post as always. Just a little gotcha: your tags vanished from the text in “the merits of using XslLink versus . I’ve been in the habit of using . ” statements. fix that with < and > for the readers to come.

  2. Marc, great post!

    I know this problem all to well! What helped to a certain extend was using an absolute link (http://www.mysite.com/ etc) instead of a relative one.

    Even weirder is that on the same page I have two webparts both using a tag: one will never give this problem the other one all the time. So I will definitly look into using the method.

    Thanks, Marja

  3. Wow! This was so helpful because I was having the same issues. Another issue that this solved was the Designer would keep stripping a leading / to a relative URL. I do have to use the full URL but it works without errors!

  4. Any other possible soultions? I see this all the time, but its not always consistent. Sometimes a page does it and sometimes not. For the path I am using the path of “/MySite/MyXSLLibrary/MyCustom.xsl” Note that the full path “Http://www.Site.com/MySite/MyXSLLibrary/MyCustom.xsl” fails with a “Named Template does not exist” error when calling the template in the custom XSL file..

    • Well please ignore the Previous somewhat late post. After looking at XSL fiel in several diferent, ways, I opened it in Notepad and noticed corruption. There were several lines that had multiple “&#160” characters inserted in a row in the middle of line of code. As if you had pressed and hold the space bar. Would really be nice to know how that happened and why I did not see them when looking at it in Sharepoint designer2010


Have a thought or opinion?