Silverlight provides very rich UI and it can used very well to communicate with SP2010. But 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 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 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 (\inetpub\wwwroot\wss\VirtualDirectories\
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.
