With the release of Silverlight 2 many people faced the task of ensuring their applications/code written targeting Beta 2 was upgraded to release.  The team at the Silverlight community site was no different.  We’ve updated almost all the content so far, but I wanted to draw your attention to a few things.

Get Started – http://silverlight.net/GetStarted

As noted on this page for those getting started, there are links to Scott Guthrie’s 8 part example of building a Digg client in Silverlight (and then using that code for a WPF desktop application).  Scott has updated his code, so that if you download the code it will be Silverlight 2 release code.  The articles themselves, however, still contain some screenshots that if you are explicitly following along might have you scratching your head.  One example is the use of the WatermarkTextBox in the screenshots and may be wondering what happened to that.  Since that control is not a part of Silverlight 2 core controls (primarily because of WPF compatibility), it isn’t in Scott’s final download.  The code still works of course so rest assured it was updated.  (Note: if you want to look at the WatermarkTextBox code it is available here.)

Learning Resources – http://silverlight.net/Learn

We’ve updated all the code downloads to contain Silverlight 2 release code updates.  One important thing to note here is that the videos don’t get a refresh.  Over time this may change as we will add more media to enhance the resources, but there’s no search/replace in video yet to make that task a simple one and the team wants to concentrate on creating new content rather than spin cycles on minor updates.  One example of where there may be some differences in the information would be in the services video.  While the concepts still apply, the notes about ensuring the configuration are correct, updating web.config, etc. are bypassed if you use the Silverlight-enabled WCF Service template in Visual Studio when creating your WCF service.  It does all that work for you (web.config, binding information, etc.).  Of course the information isn’t negated at all, for if you chose the WCF Service template (which you still can), then the steps are still valid.  The end result for both is the same however in execution (that being you end up with a WCF service that Silverlight can consume).

We fully expect there may be some of these minor differences in the video and code, but wanted to make sure that when you download the code (in C# or Visual Basic) that you are able to run it.  Should we have made a mistake, missed one, whatever, please leave a note on the comments for that video and we will rectify it immediately.

Tutorials - http://silverlight.net/learn/tutorials.aspx

Jesse has also gone through the work to update the tutorials, which are more in-depth walk-throughs, for release code as well.  There are currently 7 of them there, and will have more coming.  Because these have accompanying article (written) content, both the code and the actual tutorial itself have been updated so they should be parity with the content and code.

Hands-on Labs - http://silverlight.net/learn/labs.aspx

Okay, an admission on my part here.  In my haste, this one slipped through the cracks.  While no code is provided for 3 of the labs (they are more self-led), the Margie’s Travel site does have code.  I’m in the process now of getting these updated.  The updates should all be minor and if you download these please understand that it should be simple for you to update.  Most of the time the step involves opening the project (using the new tools), re-referencing the System.Web.Silverlight.dll assembly (as most use the asp:Silverlight control), and recompiling the application.  Not having them in release code already is an inconvenience, but doesn’t diminish the lab themselves.  If you have questions before they get updated, please let me know and I’m happy to help.

Community Gallery - http://silverlight.net/community/communitygallery.aspx

As I previously noted for gallery sample owners, the community gallery would be purged of Beta 2 samples simply because they won’t work “as-is” with the release runtime.  For now we’ve kept a category up there for old Beta 2 samples but it will not be permanent.  A lot of people have already updated and/or submitted new gallery samples for the site.  If you have a sample you’d like to submit, please feel free to contribute.

It’s our goal to ensure that the Silverlight community site is your first stop for resources.  We’re aggregating a lot of information there and a log of community blogs so I’d encourage you to visit and subscribe.

One thing that I’m just as guilty as probably most of some of my peers is creating US-centric applications.  Forgetting to think globally for your users is something that I think happens too often.  We operate in our US-centric worlds and forget that sometimes even the simplest things can make a difference.

Take for instance, honoring your user’s culture settings (region/locale/whatever you want to call it).  Even if you have a US-based application for a US-company, how do you know that a user might not be of French origin and still perhaps like to view their operating system information in French settings, so they change their culture.

Luckily in some areas this is simple to do, and for Silverlight applications you can let the platform do some of the work for you.  I’ll take a simple example of currency settings.  A colleague of mine was asking about currency formatting in his Silverlight application with regard to data binding.  He sent me a note asking why his formatter didn’t work.  He asked me why:

   1: ConverterParameter={0:$##.00}

As it turns out, it was just something missing in his implementing of a custom converter in his application.  But I let him know that he should really use {0:c} and let the platform do the work.  Let’s look at a simple example of an employee and their salary.  If we data bind this information to a DataGrid using the above formatter here is what we might get:

Makes sense right, looks fine.  Now let’s change the regional settings on my machine to French (France):

Hmm…what happened here.  Well the problem is we forced the format.  Let’s change the format parameter to {0:c} and keep French as our settings and see:

Ah, now that makes sense.  You see we can let our platform do the work and Silverlight is aware of how to use culture settings to honor currency, dates, etc. – here’s the default Calendar with French settings:

Now ideally in our sample with salaries above a literal visual translation probably isn’t accurate (by that I mean USD $1 is not the same as 1 Euro right now in translation.  We could add some custom logic though and get this output based on culture settings:

So be mindful of your applications and look for ways you can reliably and meaningfully add value to your global end users.  Don’t force a format unless you absolutely have to.

A while back I wrote to my elected officials about the passing of H.R. 1424.  I tried to be able to write to my elected officials electronically.  I submitted an electronic message to my congressman and got a reply that I’d be sent a US postal mail response, which made me shake my head.

At any rate, I’ve only got 1 response, and not from my congressman…but from one of my Senators, Jon Kyl.  Since he sent it to me via snail mail, I had to find a letter opener, figure out how to hold a piece of paper again, and scour a scanner to even report back to you here on the response.  Here it is in full:

I still call BS on some of the things.  Regardless of the explanations, it still rubs me the wrong way that these previous bills were tacked on to something called a stabilization act.  Anyway, there you go.

One of the nice little additions to the data client services in Silverlight 2 is the removal of the need to drop out of Visual Studio to do some proxy code generation.  Prior to Silverlight 2 release, if you wanted to consume an ADO.NET Data Service (the artist formerly known as Astoria), you had to drop into a command line and execute something like:

   1: datasvcutil.exe /out:"MyDataService.cs" /uri:"http://foo.com/MyDataServiceEndpoint.svc"

While that isn’t difficult, it just wasn’t convenient as a developer productivity workflow.  I mean who wants to have to click and type more than you have to, right?  After all, ADO.NET Data Service (alright forget it, I’m calling it Astoria) endpoints are services right?  And Visual Studio does have this thing called Add Service Reference?

Alas, now we don’t have to use a command-line anymore.  With Silverlight 2 and Visual Studio tools, you now can use the service reference capability I’d like to show you a screenshot, but it’s not like the dialog window is any different than other service references, so I’ll save me and you the bandwidth.  But try it out.  Take your project, add a reference to your Astoria service.

Now that Silverlight 2 has been released, one of the features (or should I say fixes) that is included is the ability for non-secure applications to call secure services.  Previously this was not allowed and we referred to it as “cross-scheme violation.”  That means that a particular protocol scheme (file, http, https) could not access another.  Prior to release this meant that a XAP hosted in an HTTP context could not call a secure service.  Now we no longer have that restriction with the release.  There are some things you have to do, so let me take a brief moment to demonstrate.

First, let’s assume this environment:

We have our application that is served from our web server via HTTP.  so our site is hosting the app on http://foo.com/MyApp.XAP.  Our service is hosted on a secure endpoint which represents our segmented API. 

NOTE: For sake of simplicity and lack of “real” hardware to actually segment out a totally representative environment.  Translated: I only have one SSL certificate and wanted to keep hosting simple…the important note is that we have two separate domains.

And what we have created here is a double-whammy – a cross-domain, secure service request.  So even though when you look at the diagram above, you might ask isn’t the client machine making the request?  Yes, but from an application with a different source-of-origin, which is what creates this scenario.  Let’s continue, shall we?

Prior to release, this simply wasn’t enabled yet.  Now that it is enabled, we can have our MyApp.xap application call our secure service (in this example is a SOAP service hosted in ASP.NET).  In Silverlight 2, the service owner still has to opt-in for this to occur.  We make use of the clientaccesspolicy.xml file which is leveraged for cross-domain scenarios (more information about cross-domain and policy files can be found here including a code snippet for Visual Studio to generate them).  In our case here we need that to support our cross-domain scenario anyway, but we’re also going to leverage it to enable non-secure callers to our service. 

Let me make that clear:  even if your secure service was hosted on the same domain as your non-secure caller, you would still need a policy file in place to enable non-secure callers.

What does the clientaccesspolicy.xml file look like then?  Here’s what we’re using for our application:

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <access-policy>

   3:   <cross-domain-access>

   4:     <policy>

   5:       <allow-from http-request-headers="SOAPAction">

   6:         <domain uri="http://*"/>

   7:         <domain uri="https://*" />

   8:       </allow-from>

   9:       <grant-to>

  10:         <resource include-subpaths="false" path="/"/>

  11:       </grant-to>

  12:     </policy>

  13:   </cross-domain-access>

  14: </access-policy>

Now that this is in place, we’re done.  Notice the two (2) domain nodes there?  I couldn’t have just put “*” in there as we require you to explicitly allow non-secure callers in this scenario.  And once you do that, if you didn’t add the secure callers (https://*) then you’d leave them out.  So although it looks a little weird (as if to say Tim, in my mind that reads “*”), it is correct.  That’s right, there isn’t anything more you need to do.  Our code would look the same.  When we add a service reference to our Silverlight application, you’ll see that the ServicesReferences.clientconfig makes note of the secure transport:

   1: <configuration>

   2:     <system.serviceModel>

   3:         <bindings>

   4:             <basicHttpBinding>

   5:                 <binding name="fooSoap" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">

   6:                     <security mode="Transport" />

   7:                 </binding>

   8:             </basicHttpBinding>

   9:         </bindings>

  10:         <client>

  11:             <endpoint address="https://www.timheuer.com/foo.asmx" binding="basicHttpBinding"

  12:                 bindingConfiguration="fooSoap" contract="Bar.fooSoap" name="fooSoap" />

  13:         </client>

  14:     </system.serviceModel>

  15: </configuration>

Here’s the rest of the code I’m using in XAML:

   1: <UserControl x:Class="XDomain.Page"

   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 

   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 

   4:     Width="300" Height="300">

   5:     <Grid x:Name="LayoutRoot" Background="White">

   6:         <StackPanel>

   7:             <TextBox x:Name="MyName" FontSize="24" />

   8:             <Button Content="Repeat" FontSize="24" Width="150" Height="50" 

   9:                     Click="Button_Click" />

  10:             <TextBlock FontSize="24" x:Name="RepeatedName" />

  11:         </StackPanel>

  12:     </Grid>

  13: </UserControl>

and the code for the event handler on the button:

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Net;

   5: using System.Windows;

   6: using System.Windows.Controls;

   7: using System.Windows.Documents;

   8: using System.Windows.Input;

   9: using System.Windows.Media;

  10: using System.Windows.Media.Animation;

  11: using System.Windows.Shapes;

  12:  

  13: namespace XDomain

  14: {

  15:     public partial class Page : UserControl

  16:     {

  17:         public Page()

  18:         {

  19:             InitializeComponent();

  20:         }

  21:  

  22:         private void Button_Click(object sender, RoutedEventArgs e)

  23:         {

  24:             Bar.fooSoapClient foo = new XDomain.Bar.fooSoapClient();

  25:             foo.SayMyNameCompleted += (sdr, args) =>

  26:                 {

  27:                     RepeatedName.Text = args.Result;

  28:                 };

  29:             foo.SayMyNameAsync(MyName.Text);

  30:         }

  31:     }

  32: }

So there you have it.  Add a simple policy file and you are enabled!  I hope this helps!  You can download a copy of this VS project here: XDomain.zip