The Silverlight 2.0 Security Model

From Script-Behind to Code-Behind

Any elements that appear in a XAML document can be scripted by the companion code that comes with the XAML resource. In Silverlight 1.0, XAML elements can only be scripted using JavaScript functions and their events can be handled exclusively through JavaScript handlers. A common naming convention entails that you name the JavaScript file that contains this code after the page that hosts the plug-in. For example, a page named default.aspx that incorporates Silverlight will be served by a script file named default.aspx.js. This is only a convention, however, and is sometimes referred to as "script-behind".

You typically create XAML documents using the new facilities in Visual Studio 2008 or Expression Studio tools. You then empower these documents using C# or Visual Basic code saved to a classic code-behind file, such as default.aspx.cs. Any code-behind class attached to a XAML document will be downloaded to the client and executed within the local machine. Here's how a XAML document links to a managed class:

<UserControl x:Class="Samples.MyPage"
   xmlns="http://schemas.microsoft.com/client/2007"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   Width="400" Height="300">
   7lt;Grid>
     :
   </Grid>
</UserControl>

The x:Class attribute on the UserControl XAML tag instructs the plug-in about the class to instantiate to start up the application. UserControl is generally the root tag of a Silverlight 2.0 page. Where does class Samples.MyPage come from? It is defined in the code-behind file of the XAML document and inherits from UserControl, as in the code snippet below:

namespace Samples
{
   public partial class MyPage : UserControl
   {
      public MyPage()
      {
          InitializeComponent();
      }
      // Event handlers and helpers go here
      :
   }
}

The x:Class attribute is the discriminating factor that enables the CoreCLR to run managed code. An XAML document that lacks the attribute can only use JavaScript to handle internal events and provide glue code.

If you use Visual Studio to develop your Silverlight 2.0 application, XAML markup and any related code are compiled into a standard .NET assembly and then packaged in a XAP file along with any required auxiliary resources such as images or perhaps script files. Additional assemblies, if necessary, are added to the XAP bundle as well. What would be the typical size of these packages? A XAP file made of a code-behind class with no external dependencies will hardly exceed 10 KB and often it is around the base size of a .NET assembly, which is 4 KB. If your code depends on external assemblies, all of them are added to the XAP. The overall size, in this case, grows up. Code reuse through assemblies is always a good practice; in Silverlight programming, though, you might want to keep an eye also on the size of the assemblies and thus organize your reusable code in relatively small and simple classes rather than compiled assemblies so that you can reuse just the pieces you need.

Is JavaScript Required to Run Silverlight 2.0 Applications?

Any Silverlight applications require a host page, be it a static HTML page or any flavors of server-side generated page. The host page includes the plug-in as an <object> tag. At least in Silverlight 1.0, it is common to rely on some boilerplate JavaScript code to create the <object> tag on-the-fly and configure it properly. As you can see, this creates a clear dependency: the browser must have JavaScript support enabled in order to run Silverlight applications. This dependency may sound reasonable in Silverlight 1.0 where JavaScript is anyway the only supported language, but is just out of place in the fully .NET-based version of Silverlight 2.0. So is JavaScript required? No, you can host and run a Silverlight application also without JavaScript. All that you have to do is adding manually an <object> tag into the page and make it point to a server-side XAP resource. The plug-in will then automatically download the XAP content, instantiate the related class, and generate any user interface in the browser.

The XAP file is a sort of zipped archive. In fact, it uses the standard ZIP compression algorithm to reduce the size of the files and minimize the client download.

The Silverlight plug-in enables .NET development across a variety of platforms including Windows, Mac and Linux and it brilliantly solves the issue of interoperability that held back the adoption of ActiveX 10 years ago. But what about security? Is it really safe to download and run compiled code over the Internet?