This chapter is from the book
This chapter is from the book
This chapter is from the book
Building a Silverlight Web Part
SharePoint ships with a web part for hosting Silverlight applications. The Silverlight Web Part project template uses this web part to host the Silverlight application. When developers create Silverlight applications for SharePoint, they generally follow one of two patterns. The first is that a Silverlight developer has created a Silverlight application and now wants to deploy it to SharePoint. The second pattern is that a SharePoint developer wants to add an existing Silverlight application to the SharePoint project. But what both of these patterns have in common is that you have one Silverlight and one SharePoint project in a single SharePoint solution and you want to connect them.
Let's take a look at an example of how to do this using the Silverlight Web Part extension project item. Create or open a Silverlight project in Visual Studio. In this example you can open the SLGrid Silverlight application that is located in the sample code, as shown in Figure 5.8.
)
Figure 5.8 SLGrid.sln Silverlight application
A developer iterates on the Silverlight application using Expression Blend or Visual Studio until it is ready to be deployed to SharePoint. The SharePoint developer adds a new empty sandboxed SharePoint project to the SharePoint solution. There are a couple of housekeeping tasks you need to do because SharePoint was added after the Silverlight project. First, set the SharePoint project as the startup project. This causes the SharePoint project to deploy to SharePoint when you press F5. You should always enable Silverlight debugging. This setting is somewhat hidden on the SharePoint tab of the Project Properties page; most of the time you need to scroll down to see the setting, as shown in Figure 5.9.
)
Figure 5.9 Enable Silverlight debugging
In your Visual Studio solution you now have one Silverlight and one SharePoint project. Technically it does not matter how you got to this state, whether you started with the SharePoint project or the Silverlight project. After you are in this state you can connect the two projects together by adding a Silverlight Web Part. Right-click the SharePoint project and add a new project item. In the new project item, click the Silverlight Web Part project item in the SharePoint\2010 node, as shown in Figure 5.10.
)
Figure 5.10 Add a Silverlight Web Part
Click Add to create the Silverlight Web Part. The Silverlight Web Part project template sees that you only have one SharePoint and one Silverlight project so it automatically connects them. If you had zero or more than one Silverlight project you would be prompted to create a new Silverlight project or select the one you would like to connect. I don't recommend using this feature because the Silverlight project is created using a default name.
The Silverlight Web Part project item template does more than just add a Silverlight Web Part to your project. First, it creates a module to deploy the Silverlight .xap file. This is equivalent to the steps you did manually earlier in this chapter. The main difference is that the Silverlight application is deployed to the Master Pages gallery. Specifically it is deployed to the ClientBin folder, and a subfolder is created that matches the package name, which is typically the same as the Visual Studio project's name. The Visual Studio replacement token, $SharePoint.Package.Name$, is used to dynamically create the folder in the Elements.xml file as shown in Listing 5.3.
Listing 5.3. Elements.xml with SharePoint Package Name Token
<?xmlversion="1.0"encoding="utf-8"?><Elementsxmlns="http://schemas.microsoft.com/sharepoint/"><ModuleName="SLGrid"Url="_catalogs/masterpage/ClientBin/$SharePoint.Package.Name$"> <FilePath="SLGrid\SLGrid.xap"Url="SLGrid.xap" /> </Module></Elements>
The project item template also creates a Silverlight Web Part definition file using the built-in Silverlight Web Part. This is equal to you manually adding a Silverlight Web Part from the Web Parts gallery. Unlike doing this manually, the web part that is created has all of the properties already set, including the URL property, which points to the location of the Silverlight .xap file. You can edit the SLGridWebPart.webpart file's properties to change other values such as description, height, width, and title. The content of SLGridWebPart.webpart is shown in Listing 5.4.
Listing 5.4. SLGridWebPart.webpart File Sets WebPart Values
<webParts><webPartxmlns="http://schemas.microsoft.com/WebPart/v3"> <metaData> <typename="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> <propertyname="HelpUrl"type="string" /> <propertyname="AllowClose"type="bool">True</property> <propertyname="ExportMode"type="exportmode">All</property> <propertyname="Hidden"type="bool">False</property> <propertyname="AllowEdit"type="bool">True</property> <propertyname="Direction"type="direction">NotSet</property> <propertyname="TitleIconImageUrl"type="string" /> <propertyname="AllowConnect"type="bool">True</property> <propertyname="HelpMode"type="helpmode">Modal</property> <propertyname="CustomProperties"type="string" null="true" /> <propertyname="AllowHide"type="bool">True</property> <propertyname="Description" type="string">SilverlightSLGrid</property> <propertyname="CatalogIconImageUrl"type="string" /> <propertyname="MinRuntimeVersion"type="string"null="true" /> <propertyname="ApplicationXml"type="string" /> <propertyname="AllowMinimize"type="bool">True</property> <propertyname="AllowZoneChange"type="bool">True</property> <propertyname="CustomInitParameters"type="string"null="true" /> <propertyname="Height"type="unit">480px</property> <propertyname="ChromeType"type="chrometype">None</property> <propertyname="Width"type="unit">640px</property> <propertyname="Title"type="string">SilverlightSLGrid</property> <propertyname="ChromeState"type="chromestate">Normal</property> <propertyname="TitleUrl"type="string" /> <propertyname="Url"type="string">~site/_catalogs/masterpage/ClientBin/$SharePoint.Package. Name$/SLGrid.xap</property> <propertyname="WindowlessMode"type="bool">True</property> </properties> </data> </webPart></webParts>
The final item created by the project item template is a test page called SLGridWebPartPage.aspx that hosts the Silverlight Web Part, SLGridWebPart.webpart. This is a nice feature for developing the solution as you immediately have a page that you can run without taking any other steps. This page uses the SharePoint Wiki Page template. The SLGridWebPartPage.aspx page is a lot of standard wiki page code; the important section is at the very bottom where the Silverlight Web Part is hosted. This is equivalent to you creating a new wiki page in the Site Pages Library and inserting the SLGridWebPart onto the page. Although it is perfectly fine to ship this with the test page, developers generally delete it before going to production. You can see Listing 5.5 for the Silverlight Web Part that is inserted in the wiki field node of the wiki page.
Listing 5.5. Silverlight Web Part in the Page Wiki Field
<!-- Silverlight Web Part --><WebPartPages:SilverlightWebPartrunat="server"Height="480px"Url="~site/_catalogs/masterpage/ClientBin /$SharePoint.Package.Name$/SLGrid.xap"ExportMode="All"ChromeType="None"ApplicationXml=""HelpMode="Modal"Description="SLGrid Web Part"ID="g_c24198d9_d504_4132_b56c_585e456d8855"Width="640px"Title="SLGrid"__MarkupType="vsattributemarkup"__WebPartId="{90D205F0-8BF4-4138-BCB5-7A947C14BDA9}"WebPart="true"__designer:IsClosed="false"></WebPartPages:SilverlightWebPart>
Though all of this detail is interesting, there is nothing that you need to change. You simply add the Silverlight Web Part and press F5 to deploy the solution to SharePoint. In this example the SLGrid application uses the client object model to display a grid of contacts, as shown in Figure 5.11.
)
Figure 5.11 Silverlight Web Part test page
Adding Silverlight Web Parts using this Project Item template is very simple to use and deploy, but it has some issues. The first is that the built-in Silverlight Web Part has a five-second timeout. This means that your Silverlight application needs to load and start up in five seconds. This is perfect for small applications, but it might be a problem for larger applications or those on slow networks. This is where the Custom Silverlight Web Part comes in. It offers another way to host your Silverlight applications. The second issue is that it is not possible to customize the web part that hosts the Silverlight control. In the next section you learn how to create and extend a custom Silverlight Web Part.