Efficient programming in Silverlight requires you to use the right tools. To get you up to speed on the latest Silverlight development tools, Cal Schrotenboer walks us through everything that comes with Silverlight Tools for Visual Studio.
December 1, 2008
| More Resources
|
The best way to get started is to go to the Silverlight Getting Started page. From there you will eventually be directed to the download page for Silverlight Tools for Visual Studio 2008 SP1 which lists the following items as its contents:
- Visual Basic® and Visual C#® Project templates
- IntelliSense® and code generators for XAML
- XAML design preview
- Debugging of Silverlight applications
- Remote debugging of Silverlight applications for Mac
- Web reference support
- WCF Templates
- Team Build and command line build support
- Integration with Expression® Blend™
Let's look at each of these in more detail but first an issue of terminology. While the Silverlight Tools download page refers to "Web reference support", what is really meant here is "Service Reference Support". While the reason for this will be explained in more detail later, to avoid confusion on the part of the reader, I will consistently refer to this as Service Reference support and not Web reference support. Also, what is meant by WCF templates is the Silverlight-enabled WCF Template. Again, for the sake of clarity, I will use the expanded description throughout this article.
Note: The RTW version of Silverlight Tools was released on October 28, about two weeks after the official release of Silverlight 2 RTW. If you installed a version of Silverlight Tools between October 14 and October 28, it is recommended that you download the new version, uninstall the old version and then install the new version.
Visual Basic and C# Project Templates
Project templates are a very convenient way to begin a project because they combine the necessary files, assembly references and project settings together into a single handy package. Once you have installed Silverlight Tools and provided that you have chosen the .NET Framework 3.5 as your target framework, selecting the Silverlight node (as shown in the following screenshot) gives you the choice of two Silverlight-specific project types: Silverlight Application and Silverlight Class Library.
 | |
| Figure 1. This screenshot shows the two Silverlight project templates which are installed by Silverlight Tools. |
The Silverlight Application template is roughly comparable to other templates designed to produce executable applications, just like the Windows® Forms Application template or the WPF Application template. The Silverlight Class Library template is roughly comparable to a Windows Class Library template or any other project designed to create a .dll file.
 | |
| Figure 2. This screenshot shows the complete collection of files created by a Silverlight Application Template when the ASP.NET® web application option is selected. |
Instead of the Form1.cs and Program.cs files that are found in the Windows Forms Application template, the Silverlight Application template provides Page.xaml and App.xaml files. Moreover, instead of the root element in Page.xaml being a Window as in the Window1.xaml file contained in a WPF Application template, the Silverlight root element is a User Control.
 | |
| Figure 3. This figure shows the XAML contents of Page.xaml as created by the Silverlight Application template. |
Every Silverlight application requires three Silverlight-specific assembly references: mscorlib, system, and System.Windows. Furthermore, in anticipation of typical Silverlight application functionality, the template also includes references to System.Core, System.Net, System.Windows.Browser and System.Xml. However, the template omits the System.Data, System.Data.DataSetExtensions, System.Deployment, System.Drawing, System.Windows.Forms and System.Xml.Linq assemblies which are provided by the Windows Forms Application template. An important effect of this combination of assemblies is to prevent the (easy) reference to classes which are inconsistent with Silverlight and which could not be processed by the Silverlight browser plugin. In fact, as the following screenshot shows, if you want to add a reference to additional assemblies, the list of available Microsoft .NET® assemblies is limited to only Silverlight-compatible choices.
 | |
| Figure 4. List of .NET Assemblies which can be added to a Silverlight Application project through Visual Studio. |
Silverlight applications require an application manifest (AppManifest.xml) in order to generate the application package and accordingly, the Silverlight Application template provides this file in the Properties folder in a C# application and in the My Project folder in Visual Basic.NET. A second file in that folder, the AssemblyInfo.cs file, is roughly comparable to the equivalent file contained in a Windows Forms or a WPF application.
Project templates are also responsible for setting various project properties. In the case of a Silverlight Application template, the Startup object is set to the App object contained in the App.xaml file. (Technically, since a Silverlight application must always be contained in a web page of some sort, this might better have been labeled the "Entry Point".) The Startup object property is unset by default in both Windows Forms and WPF applications.
 | |
| Figure 5. The Silverlight tab of a Silverlight Application's project properties. |
Although Visual Studio 2008 Professional Edition allows both Windows Forms and WPF applications to target different .NET Frameworks (versions 2.0, 3.0 or 3.5) and to select an output type (Windows Application, Console Application or Class Library), these choices are not available under the Silverlight Application template. Interestingly, all of the Silverlight assemblies carry a 2.0.5.0 version number indicating that their version number is tied to Silverlight 2 and not to any specific version of the .NET Framework (See Figure 4, above).
Silverlight applications must always be packaged in a .xap file. This is specified by the template although the developer is permitted to change the name as desired.
Silverlight content must be hosted on a web page of some type. As Visual Studio builds a Silverlight application, it gives you a choice of hosting your Silverlight content in either an ASP.NET web application or in a dynamically generated HTML page. The dynamically generated HTML page option is a convenience where you want to develop your Silverlight content independent of any additional content on the web page, perhaps because another developer has that responsibility. No setup or other effort of any sort is required when this option is selected.
However, in most instances the web application will be a preferable option because it gives you a choice of either an .aspx page or an .html page which you can then customize as a permanent container for your Silverlight content. This option is especially desirable if you plan to have additional non-Silverlight web pages or a WCF Service (discussed later) in your web site. Using a web application project also facilitates deployment because all that needs to be uploaded to your web server is the ClientBin folder, the web page hosting your Silverlight content and any other web pages (and associated assets) that you have added to the project.
 | |
| Figure 6. This figure illustrates the choice between adding an ASP.NET Web project and using a dynamically generated test page. It also illustrates that the Web project alternative has two flavors, a Web Application or a Web Site. For a description of the difference between those two choices see this MSDN article on "Introduction to Web Application Projects" and this blog entry on differences between Web application and Web site projects. If the MVC Framework is installed, a third option, an ASP.NET MVC Web Application, is also offered. |
The Debug tab for a Silverlight application offers a choice between a dynamically generated test page and a user specified html type page. This option only matters in the case where the Silverlight project is the startup project which is generally only true if the developer has declined the ASP.NET Web project choice (see Figure 6 above).
 | |
| Figure 7. The Debug tab of a Silverlight Application's project properties. |
Where the developer has chosen an ASP.NET Web project, the startup object is set by choosing the "Set as Start Page" option from the desired web page's context menu.
 | |
| Figure 8. Setting the .aspx page as the project start page. |
On the Build Tab, the Silverlight Application template disables a couple of settings which do not apply to Silverlight applications.
 | |
| Figure 9. The Build tab of a Silverlight Application's project properties. |
A Silverlight application's project properties do not include tabs for Resources, Services, Settings, Security or Publish, as is the case for a Windows Forms application. The Build Events, Reference Paths and Signing tabs are identical for both Silverlight and Windows Forms applications with the exception that ClickOnce signing is inapplicable to Silverlight applications for the obvious reason that Silverlight applications do not use ClickOnce.
The differences between a Silverlight Class Library project and a Windows Class Library project are not quite as extensive as in the case of a Silverlight Application project, but there are meaningful differences, nonetheless. Both a Silverlight Class Library project and a Windows Class Library have a code file named Class1.cs and an AssemblyInfo.cs file. The primary distinction visible in the Solution Explorer pane is the difference in referenced assemblies as illustrated in Figures 10 and 11. The explanation of these differences for a Silverlight Class Library project is the same as for a Silverlight Application project.
 Figure 10. Solution Explorer pane view of a Silverlight Class Library project. |
 Figure 11. Solution Explorer pane view of a Windows Class Library project. |
All of the project properties of a Silverlight Class Library are the same as those of a Silverlight Application except that the Class Library project cannot set its startup object or specify any build options.
Technically the Silverlight Tools package contains a third template--an items template for a Silverlight User Control which is included in a Silverlight Application template. The Silverlight User Control items template consists of a Page.xaml file and the associated code behind file, Page.xaml.cs.
 | |
| Figure 12. This screenshot shows how to add a second Silverlight User Control (equivalent to a page2.xaml) to a Silverlight project. |
IntelliSense and Code Generators for XAML
IntelliSense is Microsoft's code completion technology available for C# and Visual Basic, as well as for certain other languages, in Visual Studio, and for certain other Microsoft development tools as well. The primary benefit of IntelliSense is to provide a list of all available options, determined by the current scope, for variable names, properties, functions and methods. This is particularly helpful for methods where IntelliSense includes the applicable parameter list along with associated datatypes.
Silverlight Tools extends IntelliSense to XAML in Visual Studio. This is a major advantage for composing XAML in the Visual Studio by comparison to Expression Blend, which as of yet does not have IntelliSense for XAML.
 | |
| Figure 13. This figure illustrates the list of properties and events available to a Button element in XAML. Note that methods are not included in this list. |
The principal code generator included in the Silverlight Tools package is the Service Reference client proxy generator which is discussed below under Service Reference support.
XAML Design Preview
As of this writing, Silverlight Tools adds the read-only XAML design surface to Visual Studio. Presumably a future release will give this designer the equivalent functionality of the Windows Forms design surface. In the meantime, the best option is to use Expression Blend 2 SP1 which does have an excellent interactive design surface.
 | |
| Figure 14. Visual Studio permits a XAML page to be displayed either in code (XAML) view or in Preview mode. |
Debugging of Silverlight Applications
Silverlight Tools enables debugging in Visual Studio. If you are using an ASP.NET Web Site or Web Application, the Silverlight debugger must be enabled, which it is by default, as shown in the following screenshot of an ASP.NET Web Application's Web tab.
 | |
| Figure 15. Web tab of an ASP.NET Web Application's project properties. |
With this debugging support in place, you can set breakpoints and step through your code in the same fashion as with other Visual Studio projects.
Windbg debugging support requires a file named sos.dll. Since Silverlight is incompatible with the sos.dll file that is provided by the full .NET Framework, Silverlight Tools (via the Silverlight Developer Runtime) installs an alternate sos.dll file which does provide Windbg debugging support for Silverlight.
Remote debugging of a Silverlight application from a Mac client is even possible provided that the Silverlight 2 Developer Runtime for the Mac is installed on the client computer. Peter Laudati has written an excellent tutorial explaining how to do this.
Silverlight-enabled WCF Service Templates
Although Silverlight is entirely a client side technology, frequently it is desirable for a Silverlight application to interact with a server located somewhere on the Internet. A common example would be for a Silverlight application to store, and later retrieve, information in a remote database. Other examples would include calling any web service as for a stock quote or a weather update.
The preferred technology for communications of this type is Windows Communication Foundation (WCF). There is, however, a bit of a complication here because Silverlight is limited to only using the HTTP protocol for communications. Moreover, while WCF supports several different transport protocols including the basicHttpProtocol which is the only one that is compatible with a Silverlight client, by default WCF uses the wsHttpBinding, which unfortunately will not work with a Silverlight client. Therefore, a developer wishing to create a WCF service capable of supporting a Silverlight client must fashion at least one endpoint which uses the basicHttpBinding since this is the only binding that can be used by a Silverlight client. While it is certainly possible to do this manually, if the WCF service is intended to exclusively support Silverlight clients, it is simpler to just use the Silverlight-enabled WCF Service template for this purpose which is included in the Silverlight Tools package.
If the WCF Service is exclusively related to a single Silverlight application, it makes sense to build the WCF Service as part of the same Visual Studio solution. Right click on the Web project and choose Add New Item. This will display a dialog window which includes an entry labeled Silverlight-enabled WCF Service.
 | |
| Figure 16. This dialog window shows how to add a Silverlight-enabled WCF Service to an ASP.NET Web project. |
Selecting this option will add the .svc file and its associated code behind file to your project. It will also add references to the System.Runtime.Serialization and System.ServiceModel assemblies which are needed for WCF projects.
 | |
| Figure 17. This screenshot shows the references and files added to a Silverlight application by a Silverlight-enabled WCF Service. |
The Web.Config file is also modified by adding a section "system.serviceModel". Notably, in this section the binding for the WCF service is specified as basicHttpBinding and aspNetCompatibilityEnabled is set to true.
 | |
| Figure 18. |
When aspNetCompatibilityEnabled is set to true, hosting modes other than HTTP are not permitted for the WCF Service, even on other endpoints. In our example the only Service endpoint created by the WCF Silverlight-enabled template satisfies this constraint by using basicHttpBinding. Moreover, using only HTTP also permits the Service to offer a number of ASP.NET features such as file and URL authorization, session state, request caching, authentication and impersonation. There is an excellent discussion of this topic in Wenlong Dong's Blog.
In those cases where the WCF Service is intended to support non-Silverlight clients as well as Silverlight clients, this template is likely not appropriate. As long as at least one endpoint uses the basicHttpBinding, Silverlight clients can use the Service. However, if offering different transport protocols such as TCP or MSMQ is desirable, the aspNetCompatibilityEnabled flag would need to be set to its default value of false.
You'll also need to know that if the WCF Service will be hosted in a different domain from the Silverlight server, it will be necessary to set up cross-domain access. Instructions for how to do this are contained in the MSDN® help files.
Web Silverlight-enabled WCF Service Reference Support
A Silverlight application which needs to consume a WCF Service (or an .asmx service) requires a client side proxy through which to communicate with that service. Although this proxy is very complex and quite a task to write by hand, Visual Studio has access to a code generation library which can create this proxy for you. However, the code generation library which works for clients other than Silverlight will not work for Silverlight because the latter is limited to only a subset of the .NET Framework. To solve this problem, Silverlight Tools installs a separate code generation library (Microsoft.Silverlight.ServiceReference.dll) which will emit a Silverlight-compliant WCF Service client.
The list of components in Silverlight Tools probably should have referred to including "Service Reference Support" instead of "Web Reference Support" since the Add Web Reference option is not shown as available to Silverlight Applications as can be seen in the following screenshot.
 | |
| Figure 19. Note that Add Reference and Add Service Reference are present but Add Web Reference is not. |
The absence of the Add Web Reference option occasionally confuses developers until they are advised to simply choose the Add Service Reference option instead, as this excellent summary illustrates how to call a Web Service from a Silverlight application.
Team Build and Command Line Support
Visual Studio's Team Foundation Build is designed to provide a coordinated build process for major software projects. Team Foundation Build is capable of building code modules written in any language supported by Visual Studio and of any project type supported by Visual Studio. Silverlight Tools makes the necessary changes to Visual Studio so that Silverlight projects can be included in the Team Foundation Build process.
Silverlight developers can also use MSBuild to automate build tasks, as for example the creation of .xap packages. Dave Miles has prepared a good tutorial explaining how to use MSBuild with Silverlight content.
While most developers compile their applications (locally) by pressing either F5 or Ctrl-Shift-B, the .NET SDK includes a command line compiler, csc.exe. Silverlight Tools makes the necessary changes so that the command line compiler can also create a Silverlight .xap file.
Integration with Expression Blend
Many experienced Silverlight developers have discovered that the simultaneous use of both Visual Studio and Expression Blend is essential to an efficient development process. As previously described, Visual Studio has IntelliSense for XAML and of course is necessary for writing all event handlers. Expression Blend, on the other hand, includes an interactive design surface and is mandatory for creating most complex animations.
Fortunately, both tools use an identical project structure and are capable of opening either .sln or .proj files. Silverlight Tools adds an extra entry to the right click context menu for .xaml files in the Visual Studio Solution Explorer which offers the option to "Open in Expression Blend". This menu entry will only be displayed if Visual Studio is able to detect the presence of Expression Blend.
 Figure 20. |
 Figure 21. |
Silverlight Tools also adds a corresponding entry in the Expression Blend right click context menu which makes switching in the opposite direction equally easy.
Silverlight Developer Runtime
Installing the Silverlight Tools also results in the installation of the Silverlight Developer Runtime and the Silverlight 2 SDK.
There are both Mac and Windows versions of the Silverlight Developer Runtime. Both provide additional debug and error information. In both cases, the Developer Runtime must be installed on a client machine in order to do remote debugging. See the previously mentioned Peter Laudati blog article for an explanation of how to do this on a Mac.
Silverlight 2 SDK
The Silverlight 2 SDK contains a number of key support elements for building Silverlight applications: documentation, libraries, development tools and links to online samples.
 | |
| Figure 22. Directory structure for the Silverlight 2 SDK. |
Documentation for Silverlight takes two forms: documentation which can be incorporated into the Visual Studio built-in help files and stand alone documentation (Silverlight.chm). Obviously there is a significant advantage for Silverlight help to be available on an immediate basis simply by pressing the F1 key with the item in question selected. Unfortunately, while in most cases this integrated help will be successfully incorporated into the existing Visual Studio help files when the Silverlight Tools package is installed, this will not always occur due to different release/beta and install/uninstall combinations or because of localization mismatches. You can determine if you've achieved this integration by opening the Collection Manager in Visual Studio's built-in help. If the Microsoft Silverlight 2 SDK Documentation entry is checked, integrated Silverlight help should be available. If it is not, check it and click on the Update VSCC button.
 | |
| Figure 23. View of the Visual Studio Collection Manager. |
Silverlight help is also available in the standalone .chm file found in the SDK - Documentation - Help folder or as a separate download, independent of the SDK. This help is particularly useful for any designer or developer working exclusively in Expression Blend since there is currently no Silverlight help directly accessible from Expression Blend. Also, since Visual Studio does not currently permit filtering the integrated help files to include only Silverlight relevant content, you can achieve this result only by using the standalone help file.
The SDK also contains a "Breaking Changes" document which explains what changes in the RTW version of Silverlight 2 will cause Beta 2 Silverlight applications to no longer work.
The libraries included with the Silverlight SDK are divided into Client libraries and Server libraries. The Server libraries include two ASP.NET controls for Silverlight, asp:Silverlight and asp:MediaPlayer. Both are designed to allow developers to use the ASP.NET server control model to host Silverlight content. The media player control is designed to incorporate audio (WMA) and/or video (WMV) into a Silverlight application. The generic Silverlight Server Control is designed to host any generic XAML content. When a developer chooses to use an ASP.NET Web Application, the included .aspx page uses the asp:Silverlight control to host the XAML content provided by the Silverlight Application (See Figure 2).
The Client libraries installed by the SDK are shown in the following screenshot:
 | |
| Figure 24. Directory listing of Silverlight Client libraries included in the Silverlight 2 SDK. |
Notable assemblies in this list include System.Windows.Controls which contains the supplemental controls that are not included in the core Silverlight assemblies used by the browser plugin. These controls are the Calendar, DatePicker, GridSplitter and TabControl as shown in the following screenshot. Another key assembly is System.Windows.Controls.Data which contains the new Microsoft DataGrid.
 | |
| Figure 25. Red Gate's .NET Reflector gives this useful view of the contents of the System.Windows.Controls assembly. |
Other key assemblies include System.Xml.Linq which contains the LINQ to XML libraries and System.Xml.Serialization which contains the XML serialization libraries.
The principal development tool included in the Silverlight 2 SDK is the code generation library (Microsoft.Silverlight.ServiceReference.dll) which is use to create Silverlight compliant WCF Service client proxies.
Summary
The Silverlight Tools package contains a diverse collection of documentation, libraries and tools essential for Silverlight development using Visual Studio. The latest release represents another major milestone achieved on the path to widespread Silverlight market penetration.
Links
* This article was commissioned by and prepared for Microsoft Corporation. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.