Silverlight and Sharepoint working together: the Silverlight SharePoint Web Parts - part 1

With this article I am starting out a series focused on finding the best way to have these two technologies (Sharepoint and Silverlight) working together. 

In this series we will explore some possible ways to make Silverlight work with some of the features of Sharepoint including the less known ones.

What are we going to see in this article?

We are going to see how to embed a Silverlight application in a site page of Sharepoint in a rapid and efficient manner. In this article I already faced this topic and I described three different ways to accomplish this and in another article I presented an additional method. But now there is a recent Visual Studio extension called “Silverlight Sharepoint Web Parts” which has simplified the work of the “Sharelight” or “Silverpoint” developers. In this first part we will analyze in depth the first of the two new item templates which this extension adds to Visual Studio, and namely the “Silverlight web Part”; in the second part we will see the other one, i.e. the “Silverlight Custom Web Part”.

Two new convenient item templates for Visual Studio: the Silverlight Sharepoint Web Parts

The latest release of the Visual Studio 2010 Sharepoint Power Tools contains, amongst others, two interesting item templates useful to quickly integrate a Silverlight application in a Sharepoint project. The extension can be downloaded at the following link:

http://visualstudiogallery.msdn.microsoft.com/e8360a85-58ca-42d1-8de0-e48a1ab071c7

Once installed it adds two new options to the list of the available item templates for a Sharepoint item:

• a “Silverlight Web Part” which is the easiest and most immediate way to add a Silverlight application to a Sharepoint web page
• a “Silverlight Custom WebPart” used in more complex scenarios where, for instance, the Silverlight Client Object model is invoked.

Let’s check them out in detail.

The Silverlight Web Part

In order to use this item template the first thing to do is create a new empty Sharepoint project:

And then add a new item of type “Silverlight Web Part”:

Once added, a new dialog box will appear asking to associate the item to a Silverlight project (if already existing in the solution, but this is not our case since we started an empty Sharepoint project) or to create a new one. Let’s choose this latter option and go ahead.

In the next step it will show the well-known “New Silverlight Application” dialog box prompting whether you want to host the Silverlight application in a Web Site. Skip this option and complete the wizard. At the end your solution explorer should look like in the picture below:

Where we see that a number of components has been added to the solution:

• A new Silverlight project (SilverlighApplication1)
• A new Web Part to the Sharepoint project, called “SilverlightWebPart1”
• A new test page: “SilverlightApplication1WebPartPage.aspx”

In addition to these there are also some components working as a support for the deployment of the application in the Sharepoint environment. Sharepoint developers are quite familiar with it. For the others, such as Silverlight developers wanting to approach Sharepoint a bit more, I’ll try to recap the basic concepts in the following part:

The file “.webpart” under “SilverlightWebPart1” tree is an XML file which describes the Web Part properties and gives Sharepoint indications on how to use it.

<webParts>

  <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">

    <metaData>

      <type name="Microsoft.SharePoint.WebPartPages.SilverlightWebPart, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

      <importErrorMessage>Cannot import this Web Part.</importErrorMessage>

    </metaData>

    <data>

      <properties>

        <property name="HelpUrl" type="string" />

        <property name="AllowClose" type="bool">True</property>

        <property name="ExportMode" type="exportmode">All</property>

        <property name="Hidden" type="bool">False</property>

        <property name="AllowEdit" type="bool">True</property>

        <property name="Direction" type="direction">NotSet</property>

        <property name="TitleIconImageUrl" type="string" />

        <property name="AllowConnect" type="bool">True</property>

        <property name="HelpMode" type="helpmode">Modal</property>

        <property name="CustomProperties" type="string" null="true" />

        <property name="AllowHide" type="bool">True</property>

        <property name="Description" type="string">SilverlightSilverlightApplication1</property>

        <property name="CatalogIconImageUrl" type="string" />

        <property name="MinRuntimeVersion" type="string" null="true" />

        <property name="ApplicationXml" type="string" />

        <property name="AllowMinimize" type="bool">True</property>

        <property name="AllowZoneChange" type="bool">True</property>

        <property name="CustomInitParameters" type="string" null="true" />

        <property name="Height" type="unit">480px</property>

        <property name="ChromeType" type="chrometype">None</property>

        <property name="Width" type="unit">640px</property>

        <property name="Title" type="string">SilverlightSilverlightApplication1</property>

        <property name="ChromeState" type="chromestate">Normal</property>

        <property name="TitleUrl" type="string" />

        <property name="Url" type="string">~site/_catalogs/masterpage/ClientBin/$SharePoint.Package.Name$/SilverlightApplication1.xap</property>

        <property name="WindowlessMode" type="bool">True</property>

      </properties>

    </data>

  </webPart>

</webParts>

In particular let’s pay attention to the predefined title of the Silverlight application that Visual Studio just created for us: “SilverlightSilverlightApplication1”. We can obviously change it but the interesting thing is that this title is the one which will appear in the Web Part Gallery under “Custom” category when we try to add the Web Part to a Site page as in the picture below:

MasterPageGallery and SitePages are two modules; a module in the Sharepoint world is simply a container of master pages, web pages or web part content. A double-click on one of the modules opens the underlying Elements.xml file which contains the name of the module, its final url and the files included in it. In our case MasterPageGallery contains the .xap file and SitePages contains the test page.

Feature1: in the Sharepoint dictionary features are the gears that allow deployment of applications and functions to a Sharepoint site. They can be activated or deactivated by an administrator at farm level, site level or web application level. Feature1 in this case is an instance of feature for the deployment of the Silverlight Web Part. A double –click on the Feature1 item opens the following interface:

Where we see that the feature contains 3 items:

• .webpart file which describes the web part
• two modules MasterpageGallery and SitePages

Silverlight Web Part deployment process

The deployment of a Sharepoint web part is an easy task today: in the “Build” menu click on “Deploy Solution” and that’s it. However, it is worthwhile spending some words on the deployment process. Historically Sharepoint features, web parts, and files are deployed using a solutions file with the extension “.wsp”. Prior to Sharepoint 2010 it was often necessary to create these .wsp files manually. A .wsp files is essentially a CAB file containing all the files that must be deployed on the Sharepoint site and a set of XML-based installation instructions. To get an idea of the content of this solutions file just open the sub-folder:
…\pkg\Debug\<SilverlightWebPartProjectName> of our project:

Here you can see the exact structure and content of the .wsp file. On the root there is the assembly SilverlightWebPartProject.dll and a manifest file which describes the content of the solution. Taking a look at the manifest file:

<?xml version="1.0" encoding="utf-8"?>

<Solution xmlns="http://schemas.microsoft.com/sharepoint/" SolutionId="13dddb4d-4b46-411d-8f4f-228cfec89176" SharePointProductVersion="14.0">

  <Assemblies>

    <Assembly Location="SilverlightWebPartProject.dll" DeploymentTarget="GlobalAssemblyCache" />

  </Assemblies>

  <FeatureManifests>

    <FeatureManifest Location="SilverlightWebPartProject_Feature1\Feature.xml" />

  </FeatureManifests>

</Solution>

We notice that our solution is made of an assembly to be put in the GAC and a feature called “SilverlightWebPartProject_Feature1”. Let’s now open the folder with the name of the feature:

There are three folders containing respectively the .xap file of the Silverlight application, the “.webpart” file we already described and the test aspx page. As I already said, fortunately the creation of this WSP is no longer a task of the developer. All the stuff is managed automatically by Visual Studio. However, if you want to modify the solutions file just click on the “Package.package” tree in the Solution Explorer:

This action opens a nice interface which allows us to easily modify the WSP:

A click on the “Manifest” button in the down-left corner opens a preview of the manifest. To complete the view, take a look at the Sharepoint project properties. Click on the label “Sharepoint” at the left to open the tab of the deployment configurations. Select “Default” configuration and click on “View…” as in the picture below:

Here you see all the tasks that Visual Studio runs in the background when you launch the deployment process. Pay attention to the two checkboxes on the low-left side of the tab: the first is very useful since it allows you to debug your Silverlight application inside the Sharepoint environment. Also the second one is useful because it allows you to avoid upgrading the solution when it is still in the phase of developing and it makes no sense to keep track of all the intermediary steps. However, this last option hides a small downside: let ‘suppose you have your nice web part, a site page and then you want to debug it. When you start to debug the solution is recompiled, the previous version is retracted from the Sharepoint site and the new version is added. At the end of the debugging the solution is retracted again. This means that if you now navigate the page outside of Visual Studio you won’t see the solution in the page and you will start thinking: who the hell has taken away my web part? To see the web part again you will need to click on Menu/Build/Deploy Solution:

Using the “Silverlight Web Part”

In the previous paragraphs we have created our first Sharepoint project and then we have added the Silverlight Web Part item template which caused the addition of a new Silverlight application to the solution and the set-up of all the deployment mechanism. Now we are ready to see it in action. Just hit F5 and wait a while for the opening of the default page of our Sharepoint Site in the browser. Navigate to the “Site Pages” Library on the left and click on the test page that Visual Studio created to try out the Silverlight application:

Now you should see the Silverlight app running.

Let’s take a look at the code of the .aspx test page now. By isolating the part which embeds the Silverlight application we find:

<!-- Silverlight Web Part -->

<WebPartPages:SilverlightWebPart 

    runat="server" 

    Height="480px" 

    Url="~site/_catalogs/masterpage/ClientBin/$SharePoint.Package.Name$/SilverlightApplication1.xap" 

    ExportMode="All" 

    ChromeType="None" 

    ApplicationXml="" 

    HelpMode="Modal" 

    Description="SilverlightApplication1 Web Part" 

    ID="g_c24198d9_d504_4132_b56c_585e456d8855" 

    Width="640px" 

    Title="SilverlightApplication1" 

    __MarkupType="vsattributemarkup" 

    __WebPartId="{90D205F0-8BF4-4138-BCB5-7A947C14BDA9}" 

    WebPart="true" 

    __designer:IsClosed="false">

</WebPartPages:SilverlightWebPart>

Notice the tag: “WebPartPages:SilverlightWebPart”. It is exactly the same Web Part included in the default set of Web Parts available out of the box when editing a site page, precisely under the category “Media and Content”. Here I would refer to my article Silverlight and Sharepoint: getting started under the paragraph “The first method: using a shared Document Library” to get all the details. Normally, when using this web Part you have to load the .xap file separately in a Sharepoint Library and then tell the web part the location of the .xap file. Using this Visual Studio extension, you can avoid these boring tasks. In fact, activating the edit mode panel of the Web Part inside the page:

You notice that the path of the .xap file is already set and it is the same reported in the .webpart file above:

~site/_catalogs/masterpage/ClientBin/SilverlightWebPartProject/SilverlightApplication1.xap

Ok, nice and crystal-clear. But… what about if we want to use our Silverlight application in another site page?

Nothing complicated: thanks to the MasterPageGallery module (which we covered in the previous paragraph) our Silverlight Web Part is automatically in the set of available Web Parts under the “Custom” category:

The name of the Web Part is the result of the unhappy combination between the Silverlight app project name and the prefix “Silverlight”.

Silverlight Web Part and Silverlight Client Object Model

Now that we have our functioning Silverlight Web Part we may want to improve it for instance by adding some interaction with Sharepoint. Can we do it? The answer is “yes”, by using the Silverlight Client Object Model (SCOM). You can find further details and an example on this in my article Silverlight and Sharepoint 2010 a step forward…

But let me make a consideration: the first step when using the SCOM is to initialize a ClientContext object passing the Url of the site to it:

ClientContext myClContext = new ClientContext(siteUrl);

Obtaining the Url of the site from the Silverlight code may be not immediate in some scenarios. You can try to use the object HtmlPage.Document.DocumentUri but there is a better way to do this, and namely by using the Silverlight Custom Web Part which we will describe in the second part of this article.

Summary

In this article we have explored a new extension of Visual Studio which simplify the inclusion of Silverlight pieces in the Sharepoint environment: the Silverlight Web Part. We have learned how to use it and we have seen some hidden details related to the deployment process of a Web Part in a Sharepoint site. In the second part we will describe the other extension, the Silverlight Custom Web Part extension.