Jan Tielens' Bloggings

SharePoint 2010 and Silverlight is a fantastic combination, especially when you use the Client Object Model for Silverlight to access SharePoint data. But maybe you’ve encountered the following situation: your Silverlight application works great when it’s hosted in the out-of-the-box Silverlight Web Part, but when you build your own custom Web Part to show the Silverlight Application it just doesn’t work anymore: the browser tells you there is an Error on page. The details of the error are: Unhandled Error in Silverlight Application Object reference not set to an instance of an object.

When you debug your Silverlight code, you’ll notice that the issue is that the ClientContext.Current is a Null Reference. To solution for this problem is that fact that if you want to use the Current ClientContext you need to add the MS.SP.url parameter to the initParams in the HTML object that loads the XAP. This MS.SP.url parameter needs to contain the URL of the site in which the Silverlight Application is currently being displayed. The code of your Silverlight Web Part could look as follows:

public class SLWebPartDemo : WebPart
{
  protected override void RenderContents(HtmlTextWriter writer)
  {
    writer.Write(string.Format(
      @"<object data='data:application/x-silverlight-2,' type='application/x-silverlight-2' width='100%' height='100%'>
         <param name='source' value='{1}XAPs/SLWebPartDemoControl.xap'/>
         <param name='initParams' value='MS.SP.url={0}/{1}'/>
         <param name='onError' value='onSilverlightError' />
         <param name='background' value='white' />
         <param name='minRuntimeVersion' value='3.0.40818.0' />
         <param name='autoUpgrade' value='true' />
         <a href='http://go.microsoft.com/fwlink/?LinkID=149156&v=3.0.40818.0' style='text-decoration:none'>
          <img src='http://go.microsoft.com/fwlink/?LinkId=161376' alt='Get Microsoft Silverlight' style='border-style:none'/>
         </a>
        </object>", SPContext.Current.Site.Url,
                    SPContext.Current.Web.ServerRelativeUrl));
  }
}

If you have developed Features for SharePoint 2007, you’re probably aware of a very serious limitation of Feature Development: upgradability. Deploying version 1 of your customization is no problem, but If you want to deploy a bug fix or additional functionality in version 2, you’re basically on your own. The good news is that in SharePoint 2010, this problem is solved: as a developer you can now build features that are upgradable. The basic concept goes as follows, you built your feature as usual, and optionally you’ve got the opportunity to specify what should happen when the feature gets upgraded from a previous version.

Chris O’Brian has written an excellent series of articles about this topic, so go to his blog to read the details:

• Feature upgrade (part 1) – fundamentals
• Feature upgrade (part 2) – a sample to play with
• Feature upgrade (part 3) – introducing SPFeatureUpgrade kit
• Feature upgrade (part 4) – advanced scenarios

Many SharePoint developers know that deploying your SharePoint customization to a SharePoint server often requires you to tinker the web.config of the sites where you’d like to see the customization in action. You can do these web.config modifications manually (not advisable), or automate them with the help of the SPWebConfigModification class from the Object Model. But quite often it’s not even necessary to use that class; when you deploy your customizations with the help of a Solution (.WSP file), like you should, the Solution deployment mechanism can modify the Web.Config to apply the most commonly used changes. This is defined in the Solution Manifest of the Solution file. The following Solution Manifest will add for example a SafeControl element for the current Assembly, which is required to display controls like Web Parts, User Controls etc. in the SharePoint sites.

<Solution xmlns="http://schemas.microsoft.com/sharepoint/" SolutionId="684047e7-a990-4917-8a84-5d2ae5c8b1f3" SharePointProductVersion="14.0">
  <Assemblies>
    <Assembly Location="SafeControlsDemo.dll" DeploymentTarget="GlobalAssemblyCache">
      <SafeControls>
        <SafeControl Assembly="$SharePoint.Project.AssemblyFullName$" Namespace="SafeControlsDemo.EmptyElement1" TypeName="*" />
      </SafeControls>
    </Assembly>
  </Assemblies>
  <FeatureManifests>
    <FeatureManifest Location="SafeControlsDemo_Feature1\Feature.xml" />
  </FeatureManifests>
</Solution>

Visual Studio 2010 will automatically add the necessary SafeControl element to the Solution manifest when you add for example a Web Part item to the Visual Studio SharePoint project. But sometimes Visual Studio is not smart enough, or doesn’t have enough information to automatically do this for you. A pretty common scenario is when you build a CustomAction using the ControlClass and ControlAssembly attributes, pointing to a User Control that should be rendering the UI element defined in the CustomAction. In this case you explicitly have to add the required SafeControl element (for the User Control) to the Solution Manifest. As you probably know you can modify the Package.Template.xml to add the required SafeControl elemen, but you have to write that XML manually. A better idea is to use the power of the Visual Studio 2010 SharePoint developer tools, available out-of-the-box! The little trick is to select the item in your SharePoint 2010 project in the Visual Studio Solution Explorer window. The Properties window will show, for the selected project item, a property called Safe Control Entries.

When you click the ellipsis (the three dots), Visual Studio will show a dialog in which you can easily add the required SafeControl entries. Visual Studio will even fill out default values for you, referencing the assembly of the current project. As a result, the Solution Manifest will be updated with the corresponding XML (you can verify that by opening the Package item and selecting the Manifest view at the bottom). Easy isn’t it?