SharePoint 2010 and Silverlight – lessons learned

In these days, I’m working on the several SharePoint projects where we utilize Silverlight for the better user experience. The decision was driven by the specific requirements and not by “taste to try something new” . In one project, we are using Silverlight to build Dashboard, in another, we are using SharePoint Foundation 2010 (SPF) for public internet site, and we need to provide customers the forms to input request tickets. That second project became quite challenging for us in terms of providing custom forms in short period of time.

The problems with SPF 2010 with forms design is that SPF 2010 doesn’t support InfoPath – the simplest and fast way to provide the custom user-input form in SharePoint. We researched different alternatives, as hosting InfoPath in ASPX pages, developing XSLT forms, or ASPX layout pages,  but all of them were either too complex or didn’t meet the requirements to integrate with external Web Services and Database easily. The only one solution which could provide quick and nice UI + simplified integration with Web Services is Silverlight. So, that’s where our story begins :,,)

Despite of native Silverlight support in SharePoint 2010 there are a lot of hidden issues how to develop, debug and test SL. In this post I will share the challenges I experienced with Silverlight in SharePoint 2010 and solutions to help others to cut the corners.

1) Development

With SharePoint 2010 you can use Silverlight 3.5 or Silverlight 4.0. We had no dependency on .NET Framework version so picked the decent 4.0 version. You need to install Silverlight 4.0 Tools, SDL, WCF

When you create a new Silverlight project you will be asked if you want to host it in the external Web Application. In all articles I read they recommend not to host in external webApp and build and deploy directly to SharePoint via Features . It’s up to you if you choose that way, but for me deploying to SharePoint and testing form there is very annoying and time consuming process (it builds WSP, deploys WSP, resets IIS, SharePoint page recompiles), so I prefer to develop and deploy to the simple aspx page (TypeMock rocks in this case) and then deploy to SharePoint when necessary. The development is much faster in this case.

2) Web Services

To communicate with external systems you need to make calls ether directly from Silverlight or using Web Services. Take into account that Silverlight is the client technology and all calls will be made from the client”s browser (similar to making call to external system via javascript – JSON and REST models is what you need). It’s ok to make calls to SharePoint Object Model (Lists, Sites and etc) directly from Silverlight, but working with Database will be quire expensive in terms of loading your server with requests. In this case you need to consider creating the Web Service and call database from there.

Silverlight has limited support of SOAP services, so, consider using WCF Services, due to better support of serialized types.

3) Debugging

SharePoint Silverlight debugging in Visual Studio is not supported by default, due to Script debugging settings turned on. It means that you can’t set breakpoints and step into your code in VS if you are not deploying Silverlight controls via feature. Such functionality is supported when you host your SL project in external Web Project (another reason not to host in SharePoint during development)

To provide the SharePoint SL debugging capabilities you need to package your .XAP file in SharePoint Project (in VS) and deploy as a Feature. Such approach allows to enable “Siverlight Debugging” instead of client one, and step into your .cs code from Visual Studio 2010. This options is set from the VS IDE. Navigate to the SharePoint project properties –> SharePoint Tab –> click “Enable Silverlight Debugging”. That checkbox will activate the Remote Debugger and you will be able to debug SL hosted in SharePoint using Visual Studio 2010 (but you need to configure the Remote Debugger first, opening the firewall ports. On the 64bit windows you need to configure the x86 version of msvsmon.exe because the Visual Studio is x86)

I found really strange behaviour that debugging doesn’t work if you don’t have another instance of the the SL page opened in browser. Seems there is a bug resolving assemblies, because when you start debugging your solution might be re-builded , IIS restarts, thus remote debugger can’t attach to the right assemblies. To fix it just open another tab in browser, navigate to page with SL control you are debugging and only after that start debugging which will open the second instance of that page.

4) Deployment

You can deploy your Silverlight controls (XAP files) either externally or in SharePoint. Refer to this step-by-step instruction. Take into account that if you host Web Service outside Silverlight you need to supply ClientAccessPolicy.xml and crossdomain.xml for the cross-domain calls. Create and put these files into the root folder of SharePoint (inetpubwwwrootwssVirtualDirectories<your app port>) or into the root of the external hosing(depending the way you host SL and services)

To deploy the XAP files to SharePoint they recommend to use the following locations: SharePoint Library, “_catalogs/masterpage/”, “_layouts” or custom locations. I found that the standard SharePoint 2010 controls are stored into the “_layouts/clientbin/” folder. This folder is designed to be a standard place for hosting assemblies that are used in Silverlight. Take into account that all files deployed to SharePoint are ghostable (even you don’t specify the type), and you won’t see them on physical drive – use the SharePoint Designer to check the the file presence in the folder you deployed it.

Few words about storing the XAP in Lists. It’s might be appropriate in some scenarios, but I found that the default deployment doesn’t render the deployed file in the list 🙂 Yep it’s true, your list will be empty, nothing there, but if you type the complete URL to the file in the browser you will be prompted to download it. It looks like that the file has been actually deployed, but not exposed via the List (albeit list is created and rendered)

Web Services deployment is very easy, because Visual Studio can create the deployment package for you (right mouse click on the WCF project and select “Package”). VS will archive the solution and create the CMD script to deploy the solution to IIS. I would recommend to make additional step further and to use Web Deploy for this

————————-

That’s all for what I found to be tricky in developing Silverlight controls for the SharePoint 2010. Will update this post with further findings. If you have something to add or to share on this topic please add comments below.

7 Comments »

  1. tom Said,

    May 7, 2010@ 8:53 am      Reply

    In the deploy section you have mentioned the following
    “Refer to this step-by-step instruction”. Please update the link.

  2. Michael Said,

    May 7, 2010@ 9:10 am      Reply

    Thanks Tom. Just updated

  3. Uday Said,

    October 12, 2010@ 9:29 am      Reply

    Good job.

  4. Carl Said,

    November 24, 2010@ 3:24 pm      Reply

    Great article. I have a client who wants to use a shared hosted SP environment from a vendor like Rackspace, but they have a need for a complex order form. InfoPath would require a dedicated hosting solution which is way out of their price range. Do you know if Silverlight can be deployed on typical hosted SP environments? Any issues you can think of using SL as the interface for this?

    Thanks again.

  5. Michael Said,

    November 24, 2010@ 8:50 pm      Reply

    Silverlight works well on shared/dedicated environment. no need to modify anything there an deployment is very straightforward.
    The only issue is using Silverlight PivotViewer that require FULL trust (you can”t deploy such level to shared hosting)

  6. stena Said,

    November 26, 2010@ 1:22 pm      Reply

    Excellent post I must say.. Simple but yet entertaining and engaging.. Keep up the awesome work!
    Sharepoint 2010 supplied versatile development interface and development tools such as visual studio 2010 or sharepoint designer 2010 which enable the customers to handle the development of web part, workflow and other parts of sharepoint.
    http://www.sharepointengine.com

  7. stena Said,

    November 26, 2010@ 1:24 pm      Reply

    Excellent post I must say.. Simple but yet entertaining and engaging.. Keep up the awesome work!
    Sharepoint 2010 supplied versatile development interface and development tools such as visual studio 2010 or sharepoint designer 2010 which enable the customers to handle the development of web part, workflow and other parts of sharepoint.
    http://www.sharepointengine.com


RSS feed for comments on this post · TrackBack URI

Leave a Comment