Martin Hatch – Tales of Tech

Note – this is applicable to both SharePoint 2010 and SharePoint 2013 .. and despite rumours of “The Sandbox is deprecated” many features in SharePoint 2013 rely on the Sandbox so I don’t see it going anywhere for the time being

This is something that I have been told many times, it is not possible to embed a server control developed in the Sandbox onto a Page Layout or Master Page because you can’t add the appropriate Tag Prefix to the header.

If you consider the standard way of doing this for a Farm / Full Trust solution:

<% @Register TagPrefix="MJH" Namespace="MJH.Examples.WebControls" Assembly="MJH.Examples, Version=1.0.0.0, Culture=neutral, PublicKeyToken=16e05f568fffc0d1" %>

<!-- Custom Web Control-->
<MJH:SampleCustomControl runat="server" />

In the sandbox we obviously can’t reference the Assembly in the same way because (a) it isn’t deployed to the GAC / BIN folders and (b) it runs in a completely different process so won’t be JIT compiled by the .Net Framework… but there is a solution!

Microsoft.SharePoint.WebPartPages.SPUserCodeWebPart allows you to embed a Web Part from an assembly running in the Sandbox.

<!-- custom sandbox web part -->
<WebPartPages:SPUserCodeWebPart 
      runat="server" 
      AssemblyFullName="MJH.Examples.Sandbox, Version=1.0.0.0, Culture=neutral, PublicKeyToken=60d6fc7a560ae45c" 
     SolutionId="4faf8ff6-36ea-406f-af25-4d89472a41e1" 
     TypeFullName="MJH.Examples.Sandbox.WebParts.SampleCustomControl" >
</WebPartPages:SPUserCodeWebPart> 

You still need the “AssemblyFullName” attribute. I’ve found the easy way to get this is to add a feature receiver to a Feature in Visual Studio then copy-paste it from the Manifest in Visual Studio (which contains the full text that you need).

So thats it! Happy coding

I’ve seen this come up numerous times (with a few people telling me “its not possible without writing code”) so I thought I’d chuck up a simple code sample showing you how this is done in SharePoint 2013.

Lets say you want to add some List View Web Parts to a custom Team Site for a Tasks list:

• My Tasks
• Tasks In Progress
• Tasks Overdue

You would initially do this kind of thing in your onet.xml:

<View List="Lists/Tasks" BaseViewID="1" WebPartZoneID="Header" />
<View List="Lists/Tasks" BaseViewID="2" WebPartZoneID="Header" />
<View List="Lists/Tasks" BaseViewID="3" WebPartZoneID="Header" />

Of course the main problem here is that you have zero control over any of the Web Part properties (such as the Title, border, or anything else). The default title will use the same title as the list, which of course (when you have the same list more than once) offers the stunningly un-useful:

• Tasks (1)
• Tasks (2)
• Tasks (3)

The solution is to include some additional Web Part properties in embedded CDATA tags:

<View List="Lists/Tasks" BaseViewID="1" WebPartZoneID="Header">
  <![CDATA[
  <webParts> 
      <webPart xmlns="https://schemas.microsoft.com/WebPart/v3"> 
          <metaData> 
              <type name="Microsoft.SharePoint.WebPartPages.XsltListViewWebPart, Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> 
              <importErrorMessage>Cannot import this Web Part.</importErrorMessage> 
          </metaData> 
          <data> 
              <properties> 
                  <property name="Title">My Tasks</property>

              </properties> 
          </data> 
      </webPart> 
  </webParts>   
  ]]>
</View>

This gives you effectively complete control over any of the Web Part Properties (see XsltListViewWebPart Properties).

Happy coding!