| Comments

This morning we published the final release of the Silverlight 4 Tools for Visual Studio and WCF RIA Services.  In April, when Silverlight 4 was released, the tools were still in “RC” status.  Today, they are no longer and are officially released.  There is no new update to Silverlight itself, but these tools are the final bits of this version.

Get the Tools

If you have a clean machine you can get everything you need using the Web Platform Installer by clicking on the link at the Silverlight community site.  This will install Silverlight Tools, Silverlight, WCF RIA Services, Silverlight Toolkit and the RIA Services Toolkit in one step for you.

NOTE: If you have a previous version of the RIA Services Toolkit installed you MUST uninstall that prior to installing any new version.

Optionally you can grab the direct Silverlight 4 Tools installer here.  This will install the tools and WCF RIA Services for you and can be installed on top of any existing RC installation as it will uninstall previous tools and WCF RIA Services for you.

Watch some info about the tools and RIA Services release:

New Themes Released

Today we also are making available the final version of the 3 new application themes we developed.  These include the Accent Color, Windows 7 and Cosmopolitan themes.  The download contains Visual Studio 2010 template installers, Blend 4 compatible templates as well as the raw resource dictionary assets and sample projects.  Final versions for the RIA Services business application template will be coming as we identified some last minute changes we need to make.  You can, of course, use the raw assets and tweak them into your existing applications as needed.

NOTE: A word on ‘Cosmopolitan’ name change.  Many have asked if Metro is being renamed.  The term ‘Cosmopolitan’ refers only to the name given to this application template and is arbitrary.  Metro is the code name for the design language found in Windows Phone 7 and other applications.  It is not a literal theme name or anything else and is a term referred to internally.  This template simply was renamed to Cosmopolitan.

You can download the themes here: Silverlight 4 Application Themes.  There is a README_FIRST file explaining the different files. 

Thanks for your patience as we finalized the release of the Silverlight Tools for Visual Studio and these accompanying templates.

| Comments

You’ve written your service.  You’ve written your Silverlight application.  You Add Service Reference to your application and got the client proxy code.  Your app ‘works on your machine’ and you push it out. 



Crap.  You forgot that your service reference had your local URI endpoint in there and when you moved it to staging and/or production it failed.  You start cursing Microsoft and the Silverlight team and add to the threads in the forums or perhaps initiate a new wishlist item for the team and throw it out on Twitter and encourage votes.

It seems this is still a common frustration and people are trying to solve it in different ways.  I’m going to throw out what is my preferred mechanism and add some additional tips and tricks here that hopefully some are using.

The Setup

Here’s the setup.  You have a Silverlight application and a web service.  To keep it simple I started with File…New Silverlight Application – kept the web project there. I added a Silverlight-enabled WCF Service to my web project with this following code:

   1: [OperationContract]
   2: public string SayHello()
   3: {
   4:     // Add your operation implementation here
   5:     return "Hello World [DEVELOPMENT]";
   6: }

I then added 2 more empty ASP.NET Web Application projects to my solution, added a single Silverlight-enabled WCF Service to each one of them with the identical code, changing only the return string to PRODUCTION or STAGING to differentiate the response.  I called one project ProductionService and the other StagingService to simulate a production and staging environment.  I then added (because it wouldn’t work otherwise in my test setup) a clientaccesspolicy.xml file to the production/staging service projects.

NOTE: You may not have to do this clientaccesspolicy.xml setup.  This was only because I deployed the Silverlight app only to one web project, not others.  This may not be required for you.  See step below on Silverlight App in Same Web Project as Service section on why.

I’ve added some rudimentary XAML to the app to basically show the current default service that will be used (with the option to change it) and the response code:

Sample application snapshot

Now to explain what I’ve done/recommend.

The ServiceReferences.clientconfig ‘magic’

When you add a service reference via the Add Service References option in Visual Studio, you get a new file in your Silverlight application called ServiceReferences.clientconfig.  This contains the binding and endpoint configurations for the service you just referenced.  Here’s where you can change some things up.

By default it adds the configuration for the literal endpoint you just referenced (think absolute URI here…most of the time in development this may be localhost).  The file isn’t fixed though and you can add your other configurations there as well.  Here’s my initial updated config file with the addition of the production and staging URI endpoints.

   1: <configuration>
   2:     <system.serviceModel>
   3:         <bindings>
   4:             <customBinding>
   5:                 <binding name="CustomBinding_HelloWorldService">
   6:                     <binaryMessageEncoding />
   7:                     <httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
   8:                 </binding>
   9:                 <binding name="StagingServiceBinding">
  10:                     <binaryMessageEncoding />
  11:                     <httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
  12:                 </binding>
  13:                 <binding name="ProductionServiceBinding">
  14:                     <binaryMessageEncoding />
  15:                     <httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
  16:                 </binding>
  17:             </customBinding>
  18:         </bindings>
  19:         <client>
  20:             <endpoint address="http://localhost:40473/HelloWorldService.svc"
  21:                 binding="customBinding" bindingConfiguration="CustomBinding_HelloWorldService"
  22:                 contract="HelloServices.HelloWorldService" name="CustomBinding_HelloWorldService" />
  23:             <endpoint address="http://localhost:40848/HelloWorldService.svc"
  24:                 binding="customBinding" bindingConfiguration="StagingServiceBinding"
  25:                 contract="HelloServices.HelloWorldService" name="StagingServiceBinding" />
  26:             <endpoint address="http://localhost:40849/HelloWorldService.svc"
  27:                 binding="customBinding" bindingConfiguration="ProductionServiceBinding"
  28:                 contract="HelloServices.HelloWorldService" name="ProductionServiceBinding" />
  29:         </client>
  30:     </system.serviceModel>
  31: </configuration>

Notice the endpoint names: CustomBinding_HelloWorldService, StagingServiceBinding, ProductionServiceBinding.  The first was created for me by VS – hence the awesome hugely unhelpful name :-).  By default, if you added this code in your Silverlight application:

   1: HelloWorldServiceClient client = new HelloWorldServiceClient();

Then it will be using the default endpoint it creates (which would only be one of them unless you add custom ones like I did above).

Initializing the Service with different endpoints

Now that you know that the client config file can have multiple configuration endpoints, how would you use them?  Simple.  If you take a look at the proxy code that gets generated for you when you Add Service Reference (this is in the Reference.cs file when you use the ‘show all files’ option in VS) you’ll notice that the constructor for HelloWorldService is overloaded to allow and endpoint configuration, or optionally explicit binding/endpoint address information.  It’s the former that will make this easier for you.

Take our above ServiceReferences.clientconfig modifictation.  Let’s say we wanted to work with the staging service, we could now simply instantiate with:

   1: HelloWorldServiceClient client = new HelloWorldServiceClient("StagingServiceBinding");

In fact, I might argue that you should never use the default constructor.  Being more explicit leads to easier code to read/track in my opinion.  You don’t expect to be on this project for the rest of your life do you?  I didn’t think so…make it easier on the next developer that has to come behind you and fix your bugs enhance the code to add functionality and be explicit.

Being Dynamic about your Endpoint Initialization

Obviously you don’t want to hard-code various endpoint names in your instantiation of the service proxies.  In fact, you may be struggling because you may push your code out via automated build servers and you don’t want to have to build the XAP, then change something, blah blah.  This is where conditional compilation can help.  For instance, here’s how I have the code in this project:

   1: string _endpointName = "RelativeBinding";
   3: #if PRODUCTION
   4:     _endpointName = "ProductionServiceBinding";
   5: #endif
   7: #if STAGING
   8:     _endpointName = "StagingServiceBinding";
   9: #endif
  11: HelloWorldServiceClient client = new HelloWorldServiceClient(_endpointName);

Now I just have to make sure that my compile tasks add those conditional flags.  This is relatively simple.  You could use Visual Studio’s Configuration Build Manager to create new profiles, or you could also customize an MSBuild task to append those constants.  It is simple and there are plenty of resources to help you here.  For my project I simply customized (added) new configuration profiles in Visual Studio and have been manually switching them to test.

Silverlight App in Same Web Project as Service

But wait, there’s more!

If you have a simpler solution where your service is being served up in the same web application/site as your Silverlight application, then you have a simpler solution using Silverlight 4.  Just to clarify, what I mean by this is that your app - let’s say http://foo.com/clientbin/myapp.xap is a part of the same web application http://foo.com which serves up the service you are calling http://foo.com/helloworldservice.svc. 

Good news for you if you are using Silverlight 4.  You can now use relative path information for service references!  Let’s say your XAP is in /ClientBin/MyApp.xap and your service is in the same root location as the ClientBin folder at /HelloWorldService.svc.  This means that “../HelloWorldService.svc” will work!  I’d recommend still being explicit in your code so that it helps those come behind you.  In my client config file I added a “RelativeBinding” configuration:

   1: <endpoint address="../HelloWorldService.svc"
   2:                 binding="customBinding" bindingConfiguration="RelativeBinding"
   3:                 contract="HelloServices.HelloWorldService" name="RelativeBinding" />

and then in my code I can initiate it like I’ve done above using the named configuration.  But notice in the configuration I used ../HelloWorldService.svc as the URI for the service endpoint.  Assuming my staging and production follow the same paths, I don’t have to worry about conditional compilation, etc. and can push these out in the various environments.

Code Specific Endpoints to hide your configurations

In theory if your solution can use the relative binding scenario described above there is not too much to worry about as far as revealing too much.  However if you are using the other method about adding multiple configurations to your ServiceReferences.clientconfig file you should be aware that this file is compiled as a resource and could show others your staging/dev URIs that you may not want.  This might be a subtle by-product of getting added benefit to making the process easier though but you should be aware of these capabilities since tools like Silverlight Spy and Reflector could enable someone to look at your resource files.

You could by pass the client config named endpoints mechanism and use conditional compilation with explicit code-created endpoints.  Using the conditional statements as shown above, only the code that meets the condition will be compiled into IL.  Thus decompilation doesn’t show the other #if options.  So in Reflector or other tools you’d only see what was output.  Given this you could be even more aboslutely explicit and do something like this:

   1: BasicHttpBinding binding = new BasicHttpBinding();
   2: EndpointAddress endpoint;
   4: #if PRODUCTION
   5:     _endpointName = "ProductionServiceBinding";
   6:     endpoint = new EndpointAddress("http://myproductionserver.com/HelloWorldService.svc");
   7: #endif
   9: #if STAGING
  10:     _endpointName = "StagingServiceBinding";
  11:     endpoint = new EndpointAddress("http://mySTAGING.com/HelloWorldService.svc");
  12: #endif
  14: HelloWorldServiceClient client = new HelloWorldServiceClient(binding, endpoint);

Using this conditional compilation method you’re doing a bit more ‘hard-coding’ than relying on changing configuration and not code, but it might be more suitable to your liking.  Sure, this can still be decompiled, but it would only reveal the endpoint you already will be using (which anyone could see anyway just watching HTTP traffic).


Managing your endpoints doesn’t have to be difficult.  Hopefully these simple ways give you an idea of the options you can use.  Can we do better in helping manage this easier?  I think so.  And I know we’re thinking about it as well.

You can download my complete code sample for this application here: ManagingServiceEndpoints.zip.

Hope this helps!  (oh and hat-tip to Shawn who wrote about this for SL2…I’ve just expanded on the same idea going deeper and providing some updates for Silverlight 4)

| Comments

UPDATE: Please read the updated information on RIA Services deployment and troubleshooting on MSDN..

So you’ve been playing around with Silverlight and WCF RIA Services (the artist formerly known as .NET RIA Services) and you are ready to deploy.  You’ve been living in your happy Visual Studio environment, perhaps even relying on the built-in web server (a.k.a. Cassini) to serve up your pages/XAP to test.  All has been well, you’ve done your testing and you are ready to publish to your server.  You compile one last time and then right-click in Visual Studio on the web project and click Publish.  You push to your IIS endpoint or via FTP and the files deploy.  Sweet!  Now you go visit your site.  And it doesn’t work.  WTF?

I’ve been getting some emails on RIA Services deployment gotchas and thought I’d take a stab at explaining some of the deployment nuances. 

First it should be said that there is no greater supplement than having your dev environment match as close as possible to your ending target production environment.  If you are using IIS6 to host your final application, then it would be ideal that it is also your development/test environment.  I know this isn’t always possible for everyone, but if it is, make the effort and save yourself some time in the long run.

What is described below are some things you might run into.  Not everyone will…some will not hit any of these.  But hopefully if you do, this will be some insight.

Deploying the RIA libraries – to bin or not to bin

Your first error you may run into is assembly loading errors in your ASP.NET application.  Perhaps it says that it cannot locate or load System.Web.Ria assembly?  And here you thought the Publish command was going to deploy those for you, didn’t you (note: so did I).  Well, they aren’t.  You can do two things here.

First, you can “bin deploy” if you want.  That term means that you would deploy any non-core framework assemblies in your web applications /bin directory, making them locally available to the web application.  If you want to go this route, you can.  You have to manually go into your references in your web application and change the Copy Local property on some assemblies:

Change Copy Local Property image

The assemblies you would want to do this on (depending on what you have referenced) would be:

  • System.Web.Ria
  • System.Web.DomainServices.* (there 4 of them depending on what you are using)
  • Microsoft.RiaServices.Tools UPDATE: this assembly only required for design-time experiences

Once you do that, on your next compile, these assemblies would be copied to your bin directory and then the subsequent Publish action would also push those to your server.

The second option you have is to install the RIA Services server libraries on the server in the Global Assembly Cache (GAC).  You may have tried this already and run the RiaServices.msi installer on your server and received the warning that you are missing Visual Studio and all sorts of tools.

And then you walked away and went the bin-deploy route.  Well open up a command prompt and run this instead:

   1: msiexec /i RiaServices.msi SERVER=TRUE

And the server assemblies for RIA Services will be installed into the GAC for all to enjoy.  The advantage this has is that it becomes easier to service if you have one set of assemblies to update versus a few /bin deployed applications scurried all over the place.

HTTP Scheme violation and IIS host-headers

Now you run your application and you get this exception:

This collection already contains an address with scheme http. There can be at most one address per scheme in this collection.
Parameter name: item

Now you’re starting to wish your development environment mirrored your deployment environment aren’t you? :-)  This lovely error message will leave you wondering what is going on for a while if you didn’t know what it meant.  I mean, it’s completely descriptive isn’t it?  Of course not.

If you are getting this, you are likely running Windows 2003 server (IIS6) and are using host-headers in IIS. 

NOTE: Host headers in IIS allow you to leverage a single IP address, but have separate web sites that respond to different hostname requests.  This information is usually provided in the IIS management console and is stored in the IIS metabase.

If this isn’t you, or you aren’t controlling your server, I’m guessing you are in a shared hosting environment.

NOTE: Full trust is required for RIA Services.  UPDATE: Partial trust is supported for .NET4/VS2010, full trust requirement is only for .NET 3.5/VS2008.

Either way, what you are seeing is a limitation of Windows Communication Foundation (WCF) under .NET 3.x.  There are a few things you can do here.

If you are running .NET 3.0 (well, you likely aren’t running RIA Services then are you) – but here’s some information on creating your own ServiceHostFactory…which isn’t really an option here.

If you are running .NET 3.5 (more likely), and can get to your web.config setting, you can add this setting:

   1: <system.serviceModel>
   2:     <serviceHostingEnvironment aspNetCompatibilityEnabled="true">
   3:         <baseAddressPrefixFilters>
   4:             <add prefix="http://some.url.here.that.matches.a.host.header"/>
   5:         </baseAddressPrefixFilters>
   6:     </serviceHostingEnvironment>
   7: </system.serviceModel>

Note that the prefix you are using must match the base URI of where your DomainService will be at as well as it must exist as a mapped host-header for the site.  More information available here.

if you are running .NET 4, you may not run into this issue, but there may be an optional opt-in configuration you will have to do when .NET 4 releases.

UPDATE: HttpModule for DomainService

Perhaps one thing that I assumed was that you’d be pushing the web app completely.  But what if you already have a web.config and you aren’t pushing that over there.  Well, pay attention to the web.config of a RIA Services created project.  You’ll see an HttpModule set up (this one is from VS2010, but will be similar, just version numbers different):

   1: <httpModules>
   2:     <add name="DomainServiceModule" type="System.Web.Ria.Services.DomainServiceHttpModule, 
   3:         System.Web.Ria, Version=, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
   4: </httpModules>

If you don’t have this, then you might see some weirdness.  You see, for the default deployment, the service is handled through this module.  You may have noticed that there are no physical .SVC files in your web app.  If you look with Fiddler at your Silverlight/RIA Services application in action you’ll see something like /ClientBin/Your-Namespace-Here-Method.svc/binary.  This is actually interpreted by the module to map the request.

If you wanted to generate a physical file yourself, you can do that and the request would be processed there versus through the virtual SVC file generated.  You can read about this in Saurabh’s post.

Multiple Authentication Schemes

Okay, now you run it again and you get a message about it not supporting multiple authentication schemes and that you may have.  The message may look like this:

IIS specified authentication schemes 'IntegratedWindowsAuthentication, Anonymous', but the binding only supports specification of exactly one authentication scheme. Valid authentication schemes are Digest, Negotiate, NTLM, Basic, or Anonymous. Change the IIS settings so that only a single authentication scheme is used.

This can be a result of your <authentication> node in your ASPNET application being set to Windows, but your site being set to Anonymous in IIS.  For most, simply changing <authentication> node to mode=”Forms” will remove this error and allow you to continue.  For others, if your IIS configuration is set to use both Integrated Auth as well as Anonymous, you’ll want to uncheck one of them in the Directory Security setting for the site in IIS management console.

Install the Hotfix (XP, Vista, Windows 2003)

As noted on the RIA Services information page, if you are not running Windows 7 or Windows 2008 R2, you need to install a Hotfix.  Some people haven’t seen this note, so be sure if you fall in that category that you grab the appropriate hotfix for your architecture and run it.  UPDATE: This hotfix is only needed if you are using VS2008.

Essential Tools

So how can you troubleshoot all these things?  Some wondered where I was able to get the error messages, when their response errors in Silverlight were just showing NotFound.  I’ve said this again with regard to debugging services, especially cross-domain stuff, that if you aren’t using an HTTP diagnostic tool you are hurting your productivity in debugging.  I use Fiddler.  I used to use Web Development Helper a lot more, but have run into some problems with it registering in IE and Fiddler has finally got rid of all nuances that bothered me with it.  Some others have used Charles proxy which I’ve heard is really great, but requires Java if you don’t have it.  Any one of these tools can provide invaluable debugging information to help triage your issue.  Sometimes the HTTP response code isn’t the full story and the response body will help tremendously.

NOTE: If you are using Fiddler for http://localhost debugging, you may have seen some challenges.  In the URL, change to – noting the trailing “.” after the IP address.  Example: – this will trigger Fiddler to monitor those requests as well.

For WCF binary encoding messages, be sure to download WCF Binary-encoded message inspector if you are using Fiddler…it’s awesome (hat tip to Dan Wahlin for the tip).


I suspect anyone running into these issues above is likely using Silverlight 3/VS2008 and deploying to an IIS6 instance.  Truly this is where the issues might manifest themselves.  When WCF RIA Services comes out of beta/ctp status and releases next year, the development story will be that of Silverlight 4 and .NET 4 on the server.  As noted above, these WCF issues (with host-headers) are solved with .NET 4 on the server, so this post will be useless when the bits release.

I hoped by posting this though, that some in the interim might find some better troubleshooting tips with regard to the shared hosting scenario mostly.  I personally ran into a few of these myself on my own dedicated server that uses host-headers (but is still full trust), so I thought others might benefit from the steps that I went through to get my RIA Services application deployed on a server.

Hope this helps.

| Comments

Last week, the Silverlight 4 beta release included the Silverlight 4 Tools for Visual Studio 2010.  This single installer would perform the following (assuming you had either Visual Studio 2010 or Visual Web Developer Express 2010 already installed:

  • Install a Visual Studio 2010 service pack (KB976272)
  • Install Silverlight 4 Windows developer runtime (4.0.1108.0)
  • Install Silverlight 4 SDK
  • Install WCF RIA Services (November 2009)

That is all you really needed.  But some may have had an experience afterwards of launching VS2010 and *NOT* seeing the WCF RIA Services Class Library or Silverlight Business Application templates:

WCF RIA Services Templates in VS2010

What is happening here is that likely you already had a version of .NET RIA Services (likely the July 2009 CTP) installed.  The Silverlight tools installer silently failed and just kept going.

If you don’t see the WCF RIA Services Templates…

If you don’t see the WCF RIA Services templates, make sure Visual Studio 2010 and Visual Studio 2008 are both shutdown and perform the following:

  • Go to the Add/Remove Programs control panel application and locate .NET RIA Services.  Select the item and uninstall it.  This will remove the previous July CTP of the artist formerly known as .NET RIA Services.
  • Re-run the Silverlight Tools for Visual Studio 2010 installer. This will re-install the items and ensure that RIA Services is properly installed
    • Optionally you can extract the RIAServices.msi installer by running the tools installer with the /x:<folder> switch which will extract the contents.

After performing the above, you should now see the WCF RIA Services templates and should be working fine.

So, what happened?  Why no fail log?!

We did say beta right? :-) -- In all seriousness, we wanted to ensure that the WCF RIA Services bits got in the tools installer and knew this little inconvenience might creep up for some.  Apologies for the inconvenience.  There also exists no logging of the failure to indicate that there was anything wrong and to assist you in knowing the situation.

This is being fixed in a future installer to detect a previous install of RIA Services and alert the user (or we may even force uninstall it…not sure yet). 

But wait, RIA Services isn’t working in my Visual Studio 2008 environment now!

That’s right.  If you install RIA Services for Silverlight 4/Visual Studio 2010, it isn’t going to work in your Visual Studio 2008 environment.  If you want to work on RIA Services with Silverlight 3 and Visual Studio 2008, then you need to stick with the WCF RIA Services for VS2008 version.

Bottom line: RIA Services does not install side-by-side.

All of this information is provided to you on the WCF RIA Services web site.  The first section explains the bits you need for each environment.

Hopefully this helps clear some confusion.  Yes, I know it is frustrating not getting an error and not seeing things work.  We’re working to solve that (doesn’t help you now, I know) in future setups and make sure the release tools installer does the right thing.  It’s during these beta periods we can help identify such issues to make sure we fix them before release.

If you have questions on WCF RIA Services, be sure to head to the forums where the team is listening!

Hope this helps!

| Comments

Well, PDC09 is over and it was a blast.  What a relief it is to finally be able to show the world what the Silverlight team has been working on since Silverlight 3.  Based on the feedback at the conference, people are excited to dig into the new bits and start building solutions. 

As a round-up of resources from PDC, I’m putting some of my favorites here.

Video Content

For some of the PDC09 key Silverlight sessions, these are what I recommend:

  • CL01 – Microsoft Silverlight 4 Overview (Karen Corby)
  • CL02 – Silverlight 3 Advanced Performance and Profiling (Seema Ramchandani)
  • CL06 – Networking and Web Services (Yavor Georgiev)
  • CL07 – Mastering WCF RIA Services (Dinesh Kulkarni)
  • CL19 – Building Line of Business Applications with Silverlight 4 (David Poll)
  • CL20 – Improving and Extending the Sandbox with Silverlight 4 (Joe Stegman)
  • CL21 – Building Line of Business Applications with Silverlight and RIA Services (Brad Abrams)
  • CL22 – Advanced Topics for Building Large-scale Applications with Silverlight (John Papa)
  • CL24 – XAML Futures in Microsoft .NET Framework (Rob Relyea)
  • CL32 – Developing Testable Silverlight Applications (Keith Jones)
  • CL08 – Custom Behaviors for Advanced Microsoft Silverlight UI Effects (Peter Blois)
  • CL36 – Deep Dive on Bing maps Silverlight Control (Keith Kinnan)
  • PR03 – Integrate Microsoft Silverlight with SharePoint 2010 (Paul Stubbs)
  • FT24 – Building Extensible RIAs with Managed Extensibility Framework (Glenn Block)

These would be my “not miss” ones for Silverlight.  To help you get the videos faster, I’ve cooked up a few helpful links:

  • WMV Podcast RSS Feed (for Zune or other WMV players) – this is the WMV hi-res videos
  • iTunes/iPod Podcast RSS Feed – this is MP4 format so you can use it for any MP4 player.  As of the writing of this post, the MP4 encoding wasn’t done yet, but if you subscribe here you’ll get them when they are.
  • Windows Media Center playlist – want the 10-foot experience?  Here’s a set of playlist files for Windows Media Center.  Unzip the folder in your Public Videos folder for Media Center (or wherever you have your video content discoverable).  These point to the same hi-res videos that you would watch online.

I hope that helps get the most out of the video content for Silverlight.

Blog Content

There was some great blogging going on in the flurry of PDC and Silverlight 4 announcements as well.  Here are some I wanted to ensure you saw:

These were some of the highlights I wanted to call out.

Learning Resources

In case you missed the links in my guide post to Silverlight 4, there are 17 videos and code downloads that were launched for Silverlight 4.  In addition here’s some other resources:

Hopefully this should all get you started.  PDC was great.  Launching Silverlight 4 beta was awesome and I was able to talk to a lot of folks and get even more feedback for our requested features and what people are thinking about them.  Trust me your feedback will make it’s way back to the overall Silverlight team to see how people are using and planning to use the new features!