In this post I will show you how to create a Silverlight application that is hosted in SharePoint. Ease and grace are the keywords of course, no funky stuff.
1. Create a SharePoint project
First you need to create a SharePoint project. You can choose most of the templates. I typically use 'Empty SharePoint Project'. I could not help but name my project SilverPoint, which sounds better that ShareLight.
2. Configure the trust level
After creating the project you will hit the SharePoint Customization Wizard. The approach in this blog post allows you to use either the sandboxed or the farm solution. I will create a farm solution since I want to deploy my Silverlight XAP file into the 14\TEMPLATE\LAYOUTS\ClientBin folder. A sandboxed solution would not be allowed to deploy files into this directory.
3. Add a Silverlight project
Next add a Silverlight Application project to your solution. I will not add any custom code to the Silverlight project at this point since we'll focus on getting the Silverlight application into SharePoint.
4. Configure the deployment site
After creating the Silverlight Application you will hit the New Silverlight Application wizard. You can choose not to host the Silverlight application in a testing web site since you will use SharePoint to host it.
5. Add a Web Part to the SharePoint project
The Silverlight application needs to be loaded onto a page in SharePoint. An easy way to achieve this is to use a Web Part. Add a normal, non-visual, Web Part item to the SharePoint project. Since this Web Part will host the DemoApp Silverlight application I chose to name my Web Part DemoAppPart.
After adding this Web Part your project should be similar to the following.
6. Configure Project Output References
In the Solution Explorer, right-click the DemoAppPart folder and choose Properties in order to show the properties of this project item. In the Properties window that appears select the Project Output References property and press the ellipsis button (…) to edit the output references. Add a new output reference and configure it with the following settings.
The <projectName> in the Deployment Location is only there to reduce the chance of collisions on the server with other people's projects.
7. Delete the Web Part code
There are a few approaches to loading up the XAP that we now deploy into the ClientBin folder. You could create your own Web Part that renders out an <object> tag. However, SharePoint already ships with a Silverlight Web Part that does just that. It's called the… SilverlightWebPart. So, that means we don't have to write any code but instead can deploy this Web Part. To not deploy any code is simple. Just delete the DemoAppPart.cs file
8. Reconfigure the Web Part definition
The .webpart file points to the class that SharePoint should load when adding the Web Part to a page. Currently the .webpart file is pointing to the class that was just deleted. To rebind the .webpart file to the built-in Silverlight Web Part you change one line in the .webpart file. Change the value for the <type> element to point to the Silverlight built-in Web Part.
name="SilverPoint.DemoAppPart.DemoAppPart, $SharePoint.Project.AssemblyFullName$" />
name="Microsoft.SharePoint.WebPartPages.SilverlightWebPart, Microsoft.SharePoint, Version=220.127.116.11, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
9. Bind the XAP file
The last step is to make sure that the Web Part loads the correct XAP without the user needing to specify this. You can make use of the settings in the .webpart file to provide this configuration value.
10. Deploy and test
Hit F5 to deploy the solution and test the new Web Part.