MSDN Magazine - September 2008 - (Page 29)

Figure 4 Gathering Products in the Data Layer public List FindProductList() { var productList = new List (); using (var cn = new SqlConnection(nwCn)) { const string sql = @"SELECT p.*, c.CategoryName " + " FROM Products p INNER JOIN Categories c ON " + " p.CategoryID = c.CategoryID ORDER BY p.ProductName"; cn.Open(); using (var cmd = new SqlCommand(sql, cn)) { SqlDataReader rdr = cmd.ExecuteReader( CommandBehavior.CloseConnection); if (rdr != null) while (rdr.Read()) { var product = CreateProduct(rdr); productList.Add(product); } return productList; } } } The ClientAccessPolicy.xml file I created allows cross-domain access from all locations to all paths. A copy of this file is included in the sample application. When a WCF project is first created, the default option is to use the Visual Studio Development Server with an auto-assigned port. However, the sample application’s WCF service project is set to “Use IIS Web Server”, which can be changed in the property pages of the project on the Web tab. Either option will work, as long as the ClientAccessPolicy.xml file is placed at the Web site’s root. The policies can be restricted and secured to only allow certain URIs access to specific services in specific folder paths. To do this the Web server that hosts the Silverlight application must specified in this file so that it can talk to the WCF services. For example, a more restrictive cross-domain policy might look like this: Note here that any request originating from a service from johnpapa.net is allowed to access services in the /MyAwesomeServices path on the server. Debugging problems with cross-domain calls can be difficult. You can use a tool such as the Web Development Helper (my favorite) or Fiddler to inspect the traffic between your Silverlight application and your server-based services. These tools will show the individual HTTP requests and responses. You should also make sure your ClientAccessPolicy.xml file is put in the Web root and not the application root. I can’t stress this enough. Also, when hosting a service in a Visual Studio project (for example, not directly in IIS) and the project creates an auto-assigned port, the easiest way to test this service is just to put the ClientAccessPolicy.xml file in the root of the project itself. Because the project gets an auto-assigned port (such as localhost:32001/MyAwesomeService) it will look for the ClientAccessPolicy.xml file in root of the Web, which in this case would be localhost:32001. node in the Solution Explorer and choose Add Service Reference. Then enter the URL for the service, click the GO button, and the service will be displayed. Click OK and the service client configuration will be added to the Silverlight project along with generated proxy classes to simplify calling the services and consuming the entities (as defined by the DataContract). Figure 5 shows the dialog window that appears when adding the service. Note that the sample uses a service that, by default, is located at localhost/MySilverlightWcfService/NWServiceGateway.svc. Naturally, if the service is moved, this endpoint address will need to be updated as well. If a minor change is implemented in the WCF service, such as the addition of a new method or DataContract, you can select Update Service Reference from the Solution Explorer. Binding the Product List The sample application needs to show the list of products to the user. Here a ListBox control is used with a DataTemplate so it can present the products with a little flare beyond simply listing The Silverlight Client Once the services have been compiled and the cross-domain policies have been established, the Silverlight client can be set up to communicate with the WCF services. The sample app has a Silverlight client project called SilverlightWCF that needs a service reference to the sample’s WCF services. Right-click on the references msdnmagazine.com Figure 5 Adding a Service Reference September 2008 29 http://papa.net http://msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - September 2008

MSDN Magazine - September 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Cutting Edge Hierarchy ID New Features for Microsoft SQL Server 2008 Prism Data Services Advanced WPF Test Run Security Briefs Foundations { End Bracket }

MSDN Magazine - September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.