Silverlight 2.0

The alpha version of Silverlight 2.0 (previously referred to as version 1.1) includes a version of the .NET Framework, with the full Common Language Runtime as .NET Framework 3.0; so it can execute any .NET language including VB.NET and C# code. Unlike the CLR included with .NET Framework, multiple instances of the CoreCLR included in Silverlight can be hosted in one process. With this, the XAML layout markup file (.xaml file) can be augmented by code-behind code, written in any .NET language, which contains the programming logic. It can be used to programmatically manipulate both the Silverlight application and the HTML page which hosts the Silverlight control. Silverlight ships with a lightweight class library which features, among others, extensible controls, XML Web Services, networking components and LINQ APIs. This class library is a subset of and is considerably smaller than .NET Framework’s Base Class Library. Silverlight code runs in a sandbox which prevents invoking platform APIs. Silverlight 2.0 also adds support for DRM in media files

The version of .NET Framework in Silverlight adds a subset of WPF UI programming model, including support for shapes, documents, media and animation objects of WPF. However, the set of UI controls Silverlight ships with in the current release is limited. Also, in the current release, the UI controls do not have support for databinding to any data source. But, Microsoft has clarified that the limitations are due to this being an early preview release. Future releases will add more than 20 UI controls, add two-way databinding support, and automated layout management as well as data manipulation controls such as DataGrid. Third party libraries for expanded sets of UI controls are being made available for the alpha release as well.

Silverlight 2.0 Architecture

The included Base Class Library (BCL) provides classes for collections, reflection, regular expressions, string handling and data access. It also supports LINQ, with the full support for LINQ to Objects and expression trees. Almost all of the System.LINQ and System.LINQ.Expression namespaces are exposed. However, LINQ to XML is not present in the Silverlight 1.1 Alpha release, though further releases of Silverlight 2.0 will include it. It also supports serialization of objects, for data persistence. Silverlight can handle data in either RSS, POX, and JSON formats, in addition to XML. The BCL provides enhanced support for working with XML data, including the XMLReader and XMLWriter classes. Silverlight also includes classes for data access over XML-based Web services (POX), REST and WCF Services. The networking support in Silverlight can be used by Silverlight applications to communicate over HTTP. However, in the current release of Silverlight 1.1, cross domain communication is not allowed, though it will be in the next release of Silverlight 2.0. Silverlight also supports asynchronous programming via the use of the threading libraries

Silverlight 2.0 includes the Dynamic Language Runtime which allows dynamic compilation and execution of dynamic (scripting) languages. The first upcoming languages written for the DLR are Managed JScript, IronPython 2.0, and IronRuby. Microsoft also plan to build Visual Basic .NET 10.0 (VBx) on the DLR. All four languages share the same infrastructure to allow Silverlight to compile and execute the language source. Conversely, other .NET languages must be compiled ahead of time and delivered to Silverlight as .NET assemblies. The implementation of Managed JScript conforms to the ECMAScript 3.0 specification, and Microsoft claims that it is 250 times faster than interpreted JScript.

With the integration of .NET Framework, Silverlight also allows HTML-managed code interaction, which allows manipulation of HTML DOM elements from managed code,[13] as well as allow JavaScript code to call managed code and use objects instantiated by managed code. Silverlight encloses JavaScript objects and DOM elements in managed wrappers to make them available from managed code. However, in the 1.1 alpha release directly calling JavaScript code is not implemented, but managed code events can fire JavaScript handlers. A Silverlight instance does not need to have a UI component in order to manipulate the HTML DOM from managed code. It is done by creating a XAML Canvas with its width and height set to zero, and using its code-behind code to modify the Document Object Model of the HTML page via the APIs in the System.Browser namespace.

Silverlight 2.0 also allows limited filesystem access to Silverlight applications. It can use the operating system’s native Open file dialog box to browse to any file (which the user has access to). The file will be sanitized of path information to prevent the application from getting access to information like user name. It will be opened in read-only mode. For local storage of data, Silverlight provides isolated local storage (isostorage), which is stored, outside the browser cache, in a hidden folder inside the user profile’s private folder. In the current releases, isostorage is limited to 1 MB per URL, though this limit will later be made configurable. Data stored by a Silverlight application, identified by the URL that it loads from, can be accessed by that application only. All instances of Silverlight share the same isostorage, so all instances of a Silverlight application can share the saved data, even if they are running on different browsers.

Silverlight CoreCLR uses an attribute based security model, as opposed to the Code Access Security (CAS) model of the desktop version of .NET Framework. All assemblies are marked with a security attribute, which can be either transparent (SecurityTransparentAttribute), safecritical (SecuritySafeCriticalAttribute) or critical (SecurityCriticalAttribute). Methods in transparent assemblies runs with partial trust, and any code in such assemblies cannot call critical methods. They also cannot contain unverifiable code (use the unsafe C# keyword or use pointers) or invoke system functions by means of P/Invoke. Code in both critical and safecritical assemblies run with full trust, and are not subject to such limitations. However, critical methods can only be called from safecritical methods and not transparent methods. Thus transparent methods are prevented from using methods that can cause system wide changes. Instead, they have to call safecritical methods which will verify that the call is safe and within the limited rights of the caller, and then proxy it to the critical methods. In fact, the IsoStorage APIs are exposed as safecritical methods. An assembly that does not have any attribute set is run as a transparent method. The limitations also apply for type inheritance, virtual method calls and interface method calls as well. Silverlight assemblies can contain members that are not usable by CoreCLR but can be by .NET Framework CLR; such methods will not be loaded when the assembly is being executed by CoreCLR

Reference:

  1. Silverlight.net
  2. Microsoft Silverlight
  3. MSDN Silverlight Developer Center
  4. Silverlight architecture
  5. Silverlight 1.1 is Now Silverlight 2.0
  6. Shawn Farkas. The Silverlight Security Mode
  7. Shawn Farkas. Silverlight Security III: Inheritance
The following two tabs change content below.
Adnan Amin
Adnan is an active SharePoint MVP and having over 11 years of extensive experience with major expertise on SharePoint Server, office 365, .Net Platform and Microsoft BI, Adnan is currently working as SharePoint Architect at FMT Consultants. He is MCT Regional Lead for Pakistan Chapter since 2012. He is working on SharePoint for past seven years and worked on different intranet/intranet solutions for private & govt. sector majorly in United States and Gulf region, which include OOB and customized solutions. He is a trainer, technology evangelist and also speaks in community forums.

Leave a Reply

Your email address will not be published. Required fields are marked *