Andrew Whitechapel : Silverlight

Silverlight Web Part in SharePoint

andreww — Fri, 13 Mar 2009 07:24:00 GMT

Having looked at Silverlight in Office client, I thought I’d round out the exercise by looking at Silverlight in Office server. It turns out that lots of people have looked at this before, and I relied heavily on information from several other people’s blog posts (see below), the Silverlight Blueprint for Sharepoint, and Steve Fox and Paul Stubbs’s new book.

To host a Silverlight app in SharePoint, you’ll need the Silverlight Tools for Visual Studio 2008 sp1, which you can download for free here. You’ll also want the VS2008 Extensions for WSS 3.0 v1.3 – the latest Feb2009 CTP is available here. Make sure you read the release notes for this CTP: in particular, VSeWSS 1.3 now includes a web service that needs to run as a member of the local Administrators group – this is not done automatically on install (quite rightly), so you must set it up manually.

There are 3.5 main steps in this exercise:

· Create the Silverlight application.

· Put the Silverlight application somewhere on the server so that it is accessible from SharePoint.

· Create a web part to host the Silverlight application (this is in 2 sub-steps).

Step 1, create the Silverlight application in VS. I called my example SilverlightCoffee. Put some simple control on the page. In my example, I used a TextBlock, and I’ve set the initial content and Foreground color, plus an event handler for the MouseLeftButtonUp event.

<TextBlock x:Name="coffeeText"

FontFamily="Calibri"

FontSize="80"

FontWeight="Bold"

Foreground="#ff402010"

MouseLeftButtonUp="CoffeeText_MouseLeftButtonUp">

espresso

</TextBlock>

Add the implementation for the event handler in the Page.xaml.cs. I’ve set things up so that when you click the mouse over the app, the text and color change:

public partial class Page : UserControl

{

private bool isEspresso = true;

private SolidColorBrush latteBrush;

private SolidColorBrush espressoBrush;

public Page()

{

InitializeComponent();

latteBrush = new SolidColorBrush(

Color.FromArgb(0xff, 0xc0, 0x90, 0x50));

espressoBrush = new SolidColorBrush(

Color.FromArgb(0xff, 0x40, 0x20, 0x10));

}

private void CoffeeText_MouseLeftButtonUp(

object sender, MouseButtonEventArgs e)

{

if (isEspresso)

{

coffeeText.Text = "latte";

coffeeText.Foreground = latteBrush;

}

else

{

coffeeText.Text = "espresso";

coffeeText.Foreground = espressoBrush;

}

isEspresso = !isEspresso;

}

Build and test the Silverlight app. By default, VS will give you both a TestPage.html for testing the app in a client browser, and a SilverlightXXXTestPage.html/aspx for testing it in a web server/client browser mode.

Step 2, put the Silverlight app somewhere where SharePoint can find it. One way to do this is to create a document library on your SharePoint site to hold Silverlight applications. You can name this whatever you like, but from the code below you can see that I’ve named mine “XAPs”. Upload the Silverlight XAP to this library. You should create this document library at whatever site level makes sense on your server. For example, http://MyServer/sites/Contoso/XAPs. Note: this isn’t the only way to do this – as an alternative to using a document library, you could use IIS Manager to create a virtual directory under your SharePoint web site, map it to a physical directory, and put the XAP there instead. This approach is described in Phil Wicklund’s excellent series of posts here.

Step 3.1, create a SharePoint Web Part to host the Silverlight app. There are 2 ways to do this:

· Use one of the standard SharePoint web parts, and customize it.

· Create a completely new custom web part, using Visual Studio.

Let’s try the first approach – we’ll do the second later. Before this will work, you need to install the System.Web.Silverlight.dll from the Silverlight SDK\Libraries\Server folder to the GAC, so that SharePoint can find it. Then, go to your home page (or any page on your site), drop down the Site Actions listbox, and select Edit Page. When the page is in edit mode, click on any of the ‘Add a Web Part’ links. From the Add Web Parts dialog, find the Content Editor Web Part, check the box next to it, and click Add. Inside the CEWP, you’ll see a link to open the tool pane. Click this link, and then in the tool pane, click the Source Editor button.

Now copy the <div> for the Silverlight host control from the TestPage.html that VS generates for you for the Silverlight application project (you’ll find this in the bin\debug folder). Paste this into the Source Editor window. You need to make 3 changes to this HTML: specify explicit pixel values for the width and height of the Silverlight control; specify the same width and height for the Silverlight application within the control; and specify the full path to the XAP:

type="application/x-silverlight-2" width="400px" height="120px">

<param name="source"

value="http://MyServer/sites/Contoso/XAPs/SilverlightCoffee.xap"

</a>

</object>

</iframe>

</div>

Then exit edit mode, and click the Silverlight web part to make sure it is working, and you’re done.

Step 3.2, the second way to host the Silverlight app in a web part is to create a completely new custom web part in Visual Studio. To do this, create a SharePoint Web Part project in VS, adding it to the current solution. If you’re prompted for a trust level decision, select Partial Trust (deploy to Bin). When the project is created, rename the WebPart1 folder to something more meaningful (eg, ‘SlWebPart’) – renaming the folder should give you the option to rename all occurrences of WebPart1, including in filenames such as SlWebPart.cs. Add a reference to System.Web.Extensions and System.Web.Silverlight, and a using statement for System.Web.UI.SilverlightControls.

In the SlWebPart.cs, implement the CreateChildControls override to instantiate a Silverlight control, and set its Source property to your Silverlight XAP. Note that using SPContext requires security permissions to access the SharePoint OM, which involves additional configuration. I found some information about this on Ryan McIntyre’s blog here, but I’ve kept my example simple by specifying the fully-qualified absolute path to my Silverlight XAP.

protected override void CreateChildControls()

{

base.CreateChildControls();

Silverlight sl = new Silverlight();

sl.ID = "SlCoffee";

    //sl.Source = SPContext.Current.Site.Url+"/XAPs/SilverlightCoffee.xap";
    sl.Source = "http://MyServer/sites/Contoso/XAPs/SilverlightCoffee.xap";
    sl.Width = new Unit(400);

sl.Height = new Unit(120);

Controls.Add(sl);

}

Also override the OnLoad method to make sure we have a ScriptManager: in a SharePoint context, there should be a ScriptManager by default, so we only need to create one if there isn’t one already attached to the page.

protected override void OnLoad(EventArgs e)

{

base.OnLoad(e);

ScriptManager sm = ScriptManager.GetCurrent(this.Page);

if (sm == null)

{

sm = new ScriptManager();

Controls.AddAt(0, sm);

}

Double-check the properties for the web part project: specifically, make sure the Debug Start Action is set to start the browser with an appropriate URL. By default, this is http://localhost/, and this is often ok – but you should set it to the URL for whatever site you want the feature available on, which is not necessarily your top-level site. For example, http://MyServer/sites/Contoso/. Build the project. Then go to the Build menu and select Deploy Solution. This will deploy the web part to your SharePoint server, and activate it for the specified site.

Next, you need to make a host of changes to the web.config for your site. I found a detailed list of these changes on Phil Jirsa’s blog here, and a related video on a post by Patrick Tisseghem (thanks and RIP) here.

Finally, use your new web part on a page on your SharePoint server. Again, this requires you to install the System.Web.Silverlight.dll from the Silverlight SDK to the GAC (if you haven’t already done so). Then, go to any page on the site where this feature was deployed/activated, drop down the Site Actions listbox, and select Edit Page. When the page is in edit mode, click on any of the ‘Add a Web Part’ links. From the Add Web Parts dialog, find your SlWebPart and check the box. Then exit edit mode, and click the Silverlight web part to make sure it is working.

The screenshot below shows the results of both web part hosting techniques:

Silverlight Deep Zoom and Office Add-ins

andreww — Sun, 08 Mar 2009 06:04:00 GMT

I had some ‘free’ time today waiting to give a demo at an MVP conference session – the session over-ran, and I found myself sitting in the hallway for an hour. So I got to thinking about Silverlight and Office. If we assume that Silverlight is more or less a subset of WPF, then it makes little sense to build any Silverlight into an Office add-in: you’ve already got the regular CLR loaded, so why would you want to load a second CLR with a subset of the capabilities? Plus, there’s the performance consideration – Silverlight apps are browser-hosted, so communicating between the SL app and the rest of your solution incurs a perf penalty.

Well, I thought of a couple of possible arguments…

If you can do everything you need to do with Silverlight instead of WPF, then you might actually save some working set – since WPF is bigger than SL. Think about it: if you’re not using WPF, then you don’t have the WPF assemblies loaded. Silverlight’s coreclr + agcore + npctl = approx 2.5Mb. On the other hand, WPF’s PresentationCore + PresentationFramework + WindowsBase + WindowsFormsIntegration = approx 3.7Mb. Not a terribly convincing argument, but still.

Then there are some features that Silverlight supports that WPF doesn’t. Deep Zoom, for example. It might be difficult to imagine a use for Deep Zoom in the context of an Office add-in – but not impossible. Excel, for example, has a range of data visualization capabilities (charting, conditional formatting, heat-maps), but wouldn’t it be nice to use some Deep Zoom-like feature for pivot table drill-downs for instance? There are other features in Silverlight (and not currently supported in WPF) that might be more obviously useful in Office (specifically, the DataGrid control and the VisualStateManager), but remember this was a hallway exercise – and I like Deep Zoom.

So, I built a little proof-of-concept managed Office add-in with a custom task pane that hosts a WebBrowser control, which in turn hosts a Silverlight app. I used the Deep Zoom Composer (available for free download here) to generate the image pyramid. The Deep Zoom Composer is a very nice tool that saves an awful lot of effort in building image pyramids. It also has a very handy ‘Export to Silverlight project’ feature, which creates an entire Silverlight app solution complete with the Silverlight project itself plus an ASP.NET web app (in case you want to host the app on a server). It really couldn’t be any easier – all I had to do was build the Silverlight app – the tool even gave me a ‘TestPage.html’ which hosts the Silverlight app, so that I can test it in a browser.

Deep Zoom is documented here and here, and the Expression Blend team (that owns Deep Zoom) has a blog here. Note that the current version of the Composer tool has a maximum document size of 4 billion pixels – that’s the ‘document’ that includes all the layers of all the images in your final image set. You can easily hit this limit with just 3 or 4 images (one per layer) from a compact digital camera, depending on how much you zoom between layers. I haven’t attached a solution to this post because the image set adds up to about 30Mb.

I created a simple custom UserControl (called WebHostControl) with a fully-docked Windows Forms WebBrowser control as its only child. In my add-in class, I initialized this WebBrowser to load the TestPage.html generated by the Deep Zoom Composer. In accordance with Office UI guidelines, I set up a Ribbon customization with a ToggleButton to toggle the visibility of the task pane.

private WebHostControl whc;

private string silverlightHtml;

private CustomTaskPane slTaskPane;

private void ThisAddIn_Startup(object sender, System.EventArgs e)

{

silverlightHtml = Path.Combine(

AppDomain.CurrentDomain.BaseDirectory, "TestPage.html");

}

internal void ToggleSLTaskPane(bool isVisible)

{

if (isVisible)

{

if (whc == null)

{

whc = new WebHostControl();

}

if (slTaskPane == null)

{

slTaskPane = CustomTaskPanes.Add(whc, "Silverlight Pane");

slTaskPane.Width = 300;

}

whc.webBrowser.Navigate(silverlightHtml);

}

slTaskPane.Visible = isVisible;

}

This gets a Silverlight app running in an Office add-in. That’s a start, but it’s obviously more useful if the add-in code can communicate with the Silverlight code. Superficially, you’d think this would be easy – after all, they’re both managed components in the same process, and one is loaded (through a couple of layers) by the other. Of course, it’s not so simple – don’t forget that even though they’re both in the same process, they’re running on 2 different CLRs. For my simple PoC, I wanted the user to be able to enter a value in a cell, and have that value be used as the zoom factor in a call to zoom the image in my Silverlight app in the task pane.

Fortunately, Silverlight provides an ‘Html Bridge’ capability, documented here, which allows you to integrate script and managed code in a Silverlight app, including the ability to invoke managed code from javascript on the HTML page. So, I can communicate between the add-in code and the Silverlight code via the HTML script. To use this feature, I first changed the modifier on the Zoom method in the Page.cs in my Silverlight project, to make it public. This method is normally invoked via the mouse handlers (which is obviously a more sensible way to manipulate the zoom than using cell values – but remember this was a science experiment conducted in a hallway (without a chair, I might add)).

public void Zoom(double newzoom, Point p)

{

if (newzoom < 0.5)

newzoom = 0.5;

msi.ZoomAboutLogicalPoint(newzoom / zoom, p.X, p.Y);

zoom = newzoom;

}

Next, I created a managed class with a method that invokes the Zoom method. I exposed this method for scripting via the ScriptableMember attribute:

public class ScriptableManagedType

{

private Page thisPage;

public ScriptableManagedType(Page p)

{

thisPage = p;

}

[ScriptableMember]

public void ExposedSilverlightMethod(int cellValue)

{

thisPage.Zoom(cellValue, new Point(0.5, 0.5));

}

I instantiated this class at the end of the Page constructor, and made it available for scripting using the RegisterScriptableObject method. This method takes an arbitrary string identifier for the scriptable object – in my case I used the string “ScriptableSilverlightObject”:

ScriptableManagedType smt = new ScriptableManagedType(this);

HtmlPage.RegisterScriptableObject("ScriptableSilverlightObject", smt);

On the HTML page, make sure the Silverlight object has an explicit ID:

Then I can add some javascript to the HTML page, to get hold of the Silverlight plug-in and invoke the exposed method on the registered scriptable object. Note that the arbitrary identifier is dynamically accessible in the script from the Content property of the Silverlight plug-in:

function InvokeSilverlightMethod(cellValue)

{

var slp = document.getElementById("SLP");

slp.Content.ScriptableSilverlightObject.ExposedSilverlightMethod(
cellValue);

}

Then, in my add-in project, in my custom UserControl code, I can write a method to invoke this script:

public void InvokeScriptMethod(int cellValue)

{

this.webBrowser.Document.InvokeScript(

"InvokeSilverlightMethod", new object[] { cellValue });

}

Finally, in my ThisAddIn class, I can sink the SheetChange event and implement it to invoke the method in my UserControl.

private void ThisAddIn_Startup(object sender, System.EventArgs e)

{

silverlightHtml = Path.Combine(

AppDomain.CurrentDomain.BaseDirectory, "TestPage.html");

this.Application.SheetChange +=

new Excel.AppEvents_SheetChangeEventHandler(

Application_SheetChange);

}

void Application_SheetChange(object Sh, Excel.Range Target)

{

int cellValue = Convert.ToInt32(Target.Value2);

whc.InvokeScriptMethod(cellValue);

}

So, the sequence of operations is:

- The user changes a value in a cell in the worksheet.

- In the SheetChange event handler, I call the InvokeScriptMethod method on the UserControl that’s hosting the WebBrowser control.

- The InvokeScriptMethod invokes my InvokeSilverlightMethod javascript on the HTML page.

- The javascript method InvokeSilverlightMethod gets hold of the Silverlight object and invokes the scriptable method ExposedSilverlightMethod.

- The ExposedSilverlightMethod calls Zoom to zoom the image.

That seems somewhat painful, but right now it’s the only way (apart from some other possibly even more painful methods involving remoting or WCF or somesuch) – and it’s very nice that there is actually a way to do this kind of communication.

My conclusion here is that if you want sophisticated presentation features in your Office add-in, you’re almost certainly better off using WPF than Silverlight. Even the Deep Zoom functionality could be replicated with WPF, albeit with a lot of effort. Of course, for Deep Zoom or any WPF equivalent to be really useful as a data visualization feature in Office, you’d want to be able to compose the images dynamically – perhaps dependent on the data current in the active document/workbook. Also, the real advantage of Deep Zoom is its intelligent use of network bandwidth – which is not likely to be an issue in an Office add-in if your images are based on data from the current workbook. So, you could build a much simpler image zoom feature with WPF, without the smart download capability, using ScaleTransform. That’s a bit more work than I had time for, but this little exercise pleasantly filled up the hour’s wait in the hallway – and provided some food for thought.