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

In the first part of this article, I introduced a new extension of Visual Studio that aims to make life easier for Silverlight developers who want to get started with Sharepoint. 

In this second part we will complete the analysis with the vivisection of the second item template extension namely the “Silverlight Custom Web Part”.

The Silverlight Custom Web Part

As we did in the first part of this article, let’s start with a new empty Sharepoint project and add a new item, this time of type “Silverlight Custom Web Part”:

Once again, you will be asked to associate the item to a Silverlight project or to create a new one. Let’s choose this option and go ahead.

The Solution Explorer tree should look as in the picture below:

The structure is very similar to that on the “Silverlight Web Part”,  only an additional element makes the difference: the “SandboxedVisualWebPart1”. To better understand what it is we need to introduce some core concepts of Sharepoint 2010, which are well known by the Sharepoint developers but perhaps less known by Silverlight developers.

What is a Sandboxed Visual Web Part

As we just noticed the Silverlight Custom Web Part item template produces the inclusion of a Visual Web Part sandboxed. But, what is a Visual Web Part? And what is meant by "sandboxed"?

Visual Web Parts are a new tool in the hands of developers from Sharepoint 2010 on. They are a Visual Studio 2010 extension to create Sharepoint web parts able to host any ASP.NET control. Previously you had to refer to third part products to do this.

By choosing this option you can edit and personalize a User Control with drag&drop of objects from the toolbox. Behind the scenes Visual Studio creates a skeleton for a Web Part class and a skeleton for a User Control, then in the CreateChildControls() member function of the Web Part the User Control is added as a child control to the web Part. This brings up some security issues which will be discussed below.

From another point of view Sharepoint 2010 introduced a new concept: sandboxed solutions. When you deploy your custom solution to a Sharepoint site you are essentially deploying a piece of custom code in a Sharepoint server. This may have various impacts as you can imagine. Sandboxed solutions are a way to keep this under control. In a sandboxed solution the custom code runs in a safe sandbox, in other words it runs under some restrictions and in addition you, as a farm administrator, can set limits to these kind of solutions on the resource allocation.

Since a Visual Web Part loads a User Control (an .asxc control) which lies in ControlTemplates folder under the Sharepoint root folder it needs access to the file system and this is not allowed by the sandboxing rules. What does it mean? It means that a Visual Web Part cannot be sandboxed! And in certain scenarios this can be a limit.

This is not a real problem since there is something right for those cases: look again at the picture above and notice before the Visual Web Part another item, the “Visual Web Part (Sandboxed).” It is not part of the standard set of the item templates added to Visual Studio by an installation of Sharepoint. Instead, it comes with the installation of the Visual Studio Sharepoint Power Tools, i.e. the package you have to install to use the Silverlight Web Parts and whose link I underlined at the beginning of the article. By using a sandboxed visual Web Part you can have both the advantages of a “visual” approach in creating a web part and a safe environment. This is probably the reason why this template was used in the Silverlight Custom Web Part. In brief, in this case there is not a User Control to be loaded by the Web Part. Instead, the Web Part itself is a user control that you can edit directly, as you may notice when comparing the code initialization in both cases:

// [ initialization code of a visual web part ]

 public class VisualWebPart1 : WebPart

    {

        // Visual Studio might automatically update this path when you change the Visual Web Part project item.

        private const string _ascxPath = @"~/_CONTROLTEMPLATES/VisualWebPartProject1/VisualWebPart1/VisualWebPart1UserControl.ascx";

        protected override void CreateChildControls()

        {

            Control control = Page.LoadControl(_ascxPath);

            Controls.Add(control);

        }

    }

// [ initialization code of a sandboxed visual web part ]

public partial class SandboxedVisualWebPart1 : System.Web.UI.WebControls.WebParts.WebPart

{

    protected override void OnInit(EventArgs e)

    {

        base.OnInit(e);

        InitializeControl();

    }

    protected void Page_Load(object sender, EventArgs e)

    {

    }

}

Functioning of The Silverlight Custom Web Part

Here the core is not a standard Silverlight Web Part initialized for us by Visual Studio with the xap file transported into the Sharepoint as in the previous case. This time the core is played by the Sandboxed Visual Web Part which includes the Silverlight app in a div:

<!-- Silverlight Control -->

<div id="silverlightControlHost" style="position:relative; height:480px; width:640px;">

    <object data="data:application/x-silverlight-2," type="application/x-silverlight-2"

        width="100%" height="100%">

        <param name="source" value="<%= Microsoft.SharePoint.SPContext.Current.Web.Url %>/_catalogs/masterpage/ClientBin/CustomWebPartProject/SilverlightApplication1.xap" />

        <param name="onError" value="onSilverlightError" />

        <param name="background" value="white" />

        <param name="minRuntimeVersion" value="4.0.50401.0" />

        <param name="autoUpgrade" value="true" />

        <param name="initParams" value="MS.SP.url=<%= Microsoft.SharePoint.Utilities.SPHttpUtility.HtmlEncode(Microsoft.SharePoint.SPContext.Current.Web.Url) %>" />

        <a href="http://go.microsoft.com/fwlink/?LinkID=149156&v=4.0.50401.0" style="text-decoration: none">

            <img src="http://go.microsoft.com/fwlink/?LinkId=161376" alt="Get Microsoft Silverlight"

                style="border-style: none" />

        </a>

    </object>

    <iframe id="_sl_historyFrame" style="visibility: hidden; height: 0px; width: 0px;border: 0px"></iframe>

</div>

A deeper look at the code above reveals an interesting thing: in the initParams of the SilverlightControl is initialized using the Sharepoint Object Model server side:

<%=  Microsoft.SharePoint.Utilities.SPHttpUtility.HtmlEncode(Microsoft.SharePoint.SPContext.Current.Web.Url) %>"

What does it mean? It means that we are passing the URL of the page where the Silverlight app is hosted as a parameter. Why is it so important? We have already seen in the first part  of the article that in order to use the Silverlight Client Object Model of Sharepoint we need to know the Url of the current page. Now in the c# code of the main page of our Silverlight app we can write something like this:

namespace SilverlightApplication1
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();


            string siteUrl = App.Current.Host.InitParams["MS.SP.url"];

            ClientContext myClContext = new ClientContext(siteUrl);
        }
    }
}

In this way we can initialize at design time our ClientContext (the main object of the Silverlight Client Object Model) without knowledge of the domain in which our Silverlight application will be used. This approach is quite similar to the one I used in one of my previous articles of last year where I used a Visual Web Part ( at that time these new extensions for Visual studio were not available) to accomplish the same result .

Using the Silverlight Custom Web Part is as simple and straightforward as the Silverlight Web Part. Once deployed (the deployment mechanism is similar to that on the “Silverlight Web Part”,  ) the new web part will appear in the gallery of the Web Parts that can be added to a site page under the category “custom”:

For an example of usage of the Silverlight Client Object Model you may read my series Discover Sharepoint with Silverlight or wait for the next articles of this series.

Summary

In this article we have explored two new extensions of Visual Studio which simplify the inclusion of Silverlight pieces in the Sharepoint environment: the Silverlight Web Part and the Silverlight Custom Web Part. We have described the deployment process which allows us to use the Web Parts in a Sharepoint site. We have introduced also the reader to some peculiar concepts of the way of developing in Sharepoint, i.e. Visual Web Part and Sandboxed Visual Web Part. Finally we have seen how easy we can get access to the Silverlight Client Obect Model using the Silverlight Custom Web Part extension. In the next article we will start putting in practice what we learned here trying to create a Silverlight control menu capable of getting information from the Sharepoint navigation engine.