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.