Visual Studio 2010 replacement parameters for SharePoint projects

When building custom artifacts for SharePoint 2010, developers often need to reference post-project data at design time. A good example of this would be a reference to a fully qualified class name when developing a Web Part: When the “Web Part” Project Item is selected from Visual Studio’s “Add New Item” menu, a .webpart file is automatically generated:

<?xml version=”1.0″ encoding=”utf-8″?>
<webParts>
  <webPart xmlns=”http://schemas.microsoft.com/WebPart/v3″>
<metaData>
      <type name=”MastSPTechCon.WebPart1, $SharePoint.Project.AssemblyFullName$” />
      <importErrorMessage>$Resources:core,ImportErrorMessage;</importErrorMessage>
    </metaData>
    <data>
      <properties>
        <property name=”Title” type=”string”>WebPart1</property>
        <property name=”Description” type=”string”>My WebPart</property>
      </properties>
    </data>
  </webPart>
</webParts>

Specifically, notice the token found between the two dollar signs: $SharePoint.Project.AssemblyFullName$. When the project goes through the packaging process, Visual Studio actually parses all of the files in the packaging folder, searches for files with specific file extensions, and replaces this token with the project’s fully qualified assembly name. This is convenient since it effectively allows developers to safely rename projects and assemblies without having to worry about refactoring all of the markup contained within the projects.
#!
These replacement parameters aren’t just limited to assembly names. Another powerful token can be used to insert full type names from within a SharePoint project. For example, when the WebPart1 Project Item was created previously, a WebPart1.cs file was also created; it looked something like this:

[ToolboxItemAttribute(false)]
    public class WebPart1 : WebPart
    {
        protected override void CreateChildControls()
        {
        }
    }

If we give the WebPart1 class a unique GUID using the GuidAttribute, we can actually insert that full type name using replacement parameters.

First we add a using statement for System.Runtime.InteropServices (required for the GuidAttribute), and then our webpart1.cs file becomes:

[ToolboxItemAttribute(false)]
    [Guid(“d0fc6daa-a9d9-4b34-9c6b-cbd8de511dc9”)]
    public class WebPart1 : WebPart
    {
        protected override void CreateChildControls()
        {
        }
    }

Now, our type can be located by Visual Studio’s parameter parser, and we can actually switch our WebPart1.webpart to look like this:

<?xml version=”1.0″ encoding=”utf-8″?>
<webParts>
  <webPart xmlns=”http://schemas.microsoft.com/WebPart/v3″>
    <metaData>
      <type name=”$SharePoint.Type. d0fc6daa-a9d9-4b34-9c6b-cbd8de511dc9.AssemblyQualifiedName$” />
      <importErrorMessage>$Resources:core,ImportErrorMessage;</importErrorMessage>
    </metaData>
    <data>
      <properties>
        <property name=”Title” type=”string”>WebPart1</property>
        <property name=”Description” type=”string”>My WebPart</property>
      </properties>
    </data>
  </webPart>
</webParts>

Notice the new replacement parameter we’ve included: It references the same GUID on our WebPart1 class. Now, using this replacement parameter, if we have to refactor our type name or namespace, we don’t have to worry about crawling through our .webpart file to prevent regression issues! This exact pattern is used within SharePoint 2010 Feature Receivers created within Visual Studio.

Visual Studio 2010 Replacement Parameters for SharePoint 2010 projects are extremely powerful and can remove some of the custom markup pain that SharePoint developers still have to endure. A full list of these tokens, as well as how to apply the replacement to additional file types, can be found on MSDN. Another example of using these replacement parameters can also be found on my blog, where I provide steps for creating an HttpHandler to be deployed to SharePoint.

Jonathan Mast is a senior SharePoint consultant at SharePoint911, a Rackspace company.