Last time we discussed how to integrate a custom control into an XSL transformation. The key point to note about the previously discussed approach is that all the markup is output by the overridden Render method. This can easily get cumbersome and ineffective for complex server side controls. The ASP.net stack offers us a solution to this common problem with Control definitions. This solution is a UserControl which adds a special ASCX file containing declarative markup which makes the development task much easier, simpler & cleaner.

In this post, we will show how to incorporate a server side UserControl with markup in it’s ASCX file to render within an XSLT instead of a simple Control definition.

How to do this

In order to render a UserControl ASCX within an XSLT, we need to follow a slightly different method that the one discussed in the previous post. Here are the steps-

1. First thing we need to do is to define our user control. Here is a sample ASCX definition. Notice that this control renders a variable called ‘Input’ which we will also define in the code-behind class in the next step-
   
   

   <%@ Assembly Name="$SharePoint.Project.AssemblyFullName$" %>
   <%@ Assembly Name="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
   <%@ Control Language="C#" AutoEventWireup="true" CodeBehind="DemoControl.ascx.cs" Inherits="Demo.ControlTemplates.DemoControl" %>
   
   <div>(<%= Input %>)</div>

2. Next, we define the code-behind that our ASCX inherits from. Notice that we are declaring a public string property called ‘Input’ whose value is being directly rendered within the ASCX as an example. This variable is used to accept contextual information about the XML node being processed by the XSL transform at the time of evaluating this control during the runtime-
   

   using System.Web.UI;
   
   namespace Demo.ControlTemplates
   {
       public partial class DemoControl : UserControl
       {
           public string Input;
       }
   }
3. Next, we need to globally register our user control so that our XSLT can find it. This is done because we don’t have the ability to register custom user controls from within an XSLT webpart. The following registration happens in the web.config in this node: <configuration>…<system.web>…<pages>…<controls>. Notice that we assign a tagName for this user control. This tag name will be used when we reference the user control in our XSLT-
   

   <add tagPrefix="PSControl" src="/_controltemplates/demo/democontrol.ascx" tagName="PSC"/>

4. Now that SharePoint globally knows about this user control, we need to modify our xsl declaration to assign a tag prefix for this control so that we can reference it wherever we want to use it. In this case, our tag prefix is ‘PSControl’-
   

   <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:PSControl="Demo.ControlTemplates" >

5. Now that everything has been setup, we can simply reference our custom user control using the tag prefix defined in step 4 (PSControl) and the tag name defined in step 3 (PSC). Combined this tag declaration allows us to render our custom user control ASCX which was written declaratively to save development time associated with defining a custom server side control for our XSLT. Notice that we are using the Input property defined in the UserControl and passing it contextual value about the current node  being processed in this case-
   

   <PSControl:PSC Input="{title}" runat="server" />

That’s it! You can now write declarative markup in a UserControl ASCX file and have that markup process XML nodes using a code-behind, all within the context of an XSL transform.

SharePoint relies heavily on XML data and XSLT processing of such data. Whether we are dealing with Search results, Data view web parts or Content Query web parts, XSLT processing is something all SharePoint developers have to deal with on regular basis. SharePoint provides an XSLT extension object called ddwrt to perform tasks such as accessing properties of a SharePoint list or firing events to connected Web Parts.

Even though XSL transforms are incredibly powerful, especially with the availability of extension objects like ddwrt, sometimes it is much quicker and easier to perform advanced processing using server side controls. In other cases, it’s almost a necessity. Imagine being able to take xml data and query external web services during the transformation process to render customized contextual information about the data being displayed to the user.

For example, let’s say we were to implement a staff directory using SharePoint people search. The underlying data is stored in the User Profile service application and the results are rendered using the people core results web part. However what if instead of simply displaying a list of people, we additionally wanted to display a list of projects that they are participating in? In this case, imagine the power of being able to insert a server side control in the XSLT to query a 3rd party project management system to retrieve the list of a particular user’s projects and then rendering that nested within the rest of the XSL transform

How to do it

There are 4 steps needed in order to be able to insert server side controls within a SharePoint XSLT-

1. First thing we need to do is to write the control that we will be inserting into our XSLT. Notice that we are declaring two public properties called ‘itemUrl’ and ‘print’. These properties are used to pass xml data at run-time into our control. We are also overriding the Render method which is used to spit out the code that will be output to the end user-

namespace PortalSolutions.WebUI.Controls
{
    public class SampleFields : Control
    {
        public string itemUrl;
        public string print;

        protected override void Render(HtmlTextWriter writer)
        {
            writer.Write("<div>Hello World</div>");
        }
    }
}

2. The next thing for us to accomplish is to globally register our assembly and a tagPrefix for this assembly so that SharePoint can find our control. This is done because we don’t have access to register our assembly from within the XSL editor on SharePoint web parts. This registration is added in the web.config under the following node:  <configuration>…<system.web>…<pages>…<controls>-
   

   <add tagPrefix="PS" namespace="PortalSolutions.WebUI.Controls" assembly="PortalSolutions.WebUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=00aaa666444222cc" />

3. Now that SharePoint knows about our assembly and can find the control, we have add a declaration on top of XSL to attach a prefix to our namespace so that we can reference our control. In this case, ‘PS’ is the tag prefix we will be using-
   

   <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:PS="PortalSolutions.WebUI.Controls" >

4. Finally, now that we have everything set, we simply have to reference our control where we want to render it by using our tag prefix we registered in step 3 and the name of our control class which in this case is ‘SampleFields’. Additionally we use the public properties declared in the control definition as attributes in our XSL to pass in any information that the control may need to process the current XML node-
   

   <PS:SampleFields itemUrl="{$url}" print="HelloWorld" runat="server" />

And there we have it! A custom server side control puts a lot of power in the hands of developers looking to deliver some really powerful and amazing solutions.

The typical answer is to write a custom core results webpart, but what about the other related webparts? You could in theory write a new paging webpart and a new search actions webpart and so on but wouldn’t it be nice if all these related webparts just worked with your new core results webpart? The answer is that they can but you have to get a little creative about modifying the SearchResultsHiddenObject. Here is an example where we disable duplicate trimming for correct paging behavior-

object srho = HttpContext.Current.Items["OSSSRHDC_0"];
if (srho != null)
{
    Type srhoType = srho.GetType();
    FieldInfo startAt = srhoType.GetField("_DuplicatesRemoved", BindingFlags.Instance | BindingFlags.NonPublic);
    startAt.SetValue(srho, false);
}

Here is a great walkthrough by Corey Roth on this topic: http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2008/06/09/new-web-part-for-wildcard-search-in-enterprise-search.aspx

Solution
When you upload a list template (STP) using a feature to the list template gallery ( _catalogs/lt ), you must set some attributes in order for the template to show up on the create.aspx page-

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <Module Url="_catalogs/lt" Name="PS.AACP.Stp" Path="">
        <File Url="StpTest.stp" Type="GhostableInLibrary" IgnoreIfAlreadyExists="TRUE">
           <Property Name="Title" Value="StpTest" />
           <Property Name="Language" Value="1033" />
           <Property Name="FeatureID" Value="{D90095AD-86D4-4e55-AE28-119E21530552}" />
        </File>
    </Module>
</Elements>

Upon further investigation I found out from the IIS logs on the target machine that all the exported .cab files were actually being transferred over successfully and IIS was returning back a status code of 200 for each transfer. However on the last CAB file upload, IIS returned a status code of 400 every time for some reason. After that, everything just died out and the source machine could not confirm that the transfer was complete.

Rob has a more detailed account of why SP2 broke Content Deployment but in short, the fix involved making changes to the registry since service pack 2 has issues with networking and I am being told that there is no way to roll-back from SP2.

However, if you want to make changes to how the alert email looks – perhaps to make the email look more like your corporate emails – you have to modify a file called alerttemplates.xml located in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\XML. Combined-Knowledge has a great white-paper on how to do so.

However, I just wasted a bit of my time figuring out why my changes were not taking effect. It turns out that after making changes to your alert template, you must use the stsadm -o updatealerttemplates to update the alert template for the site collection you want. Then you MUST re-subscribe yourself to receive the alert by clicking “Actions > Alert Me“

It appears that the site creates a separate alert template for each user. Seems inefficient if it is true – can someone confirm this?