When working with data and Silverlight there has often been the questions of wondering why when a service call fails that Silverlight returns the HTTP 404 status code.  In fact I’ve written about troubleshooting those types of issues in the past and tools you can use to help investigate some problems.

Still people mostly ask "if there is an exception, why is Silverlight telling me ‘not found’ instead of sending me the exception?'”  Eugene Osovetsky from the connected systems team aims to answer those questions in a recent post with a little more detail than has been provided in the past as well as offering some suggestions.  From his post, this is one of the main reasons which I’ve echoed in discussions, webcasts, forums in the past as well:

“Unfortunately, web browsers have a limitation with regards to status codes: When a browser plugin (such as Silverlight) makes an HTTP request, and the response status code is not 200, the browser hides the actual status code and the message body from the plugin. All Silverlight knows is that "something went wrong", but it has no way of discovering any details.”

Take a look at Eugene’s post for some other helpful suggestions.

You may be reading the title and wondering what is MediaStreamSource?  MediaStreamSource is a piece of the Silverlight runtime that removes a the influence of a media file's container, giving developers direct access to APIs for manipulating encoded elementary audio and video streams.

Huh?

Basically it can enable you as the developer to implement file parsers/etc. in managed code instead of Silverlight, enabling support beyond the native built-in formats for media.  There hasn’t been much information about these types of topics, and I’d agree that for the mainstream, they may be a bit more advanced media scenarios for when the default containers and formats aren’t enough for your use.  Outside of the MSDN documentation there hasn’t really been any good samples of this use either.

Until now.

One of the program managers on the Silverlight media team, Larry Olson, has just provided a detailed public sample of the MediaStreamSource in action on the MSDN Code Gallery site.  He calls the effort ManagedMediaHelpers.  The project contains:

• Silverlight class library (MediaParsers) which has helper classes for working with MP3 files, including being able to find the right point in an MP3 to begin playback.
• Silverlight test project for NUnit
• Silverlight class library (Mp3MediaStreamSource) which has logic for using MP3 file streams
• Silverlight Application Demo which shows the interaction between a MediaElement and a MediaStreamSource

Why would you want this?  Larry outlines in the project:

“For one thing, having access to elementary streams means that developers can now implement scenarios that other solutions haven't necessarily provided thus far. One example of this is adaptive streaming or multi-bitrate support as was seen during the 2008 Olympics.

For another reason, having access to elementary streams allows developers to implement scenarios that the Silverlight runtime hasn't had a chance to implement yet or that the runtime might not be able to implement in the same timeframe that a developer wants it. Examples of this could be, RTSP:T protocol support, SHOUTcast protocol support, seamless audio looping, ID3 v1 and ID3 v2 metadata support, and many other scenarios.”

This is a great sample and source for those working with media within Silverlight.  Right now it is audio only, MP3 support, but gives you an idea of the MediaStreamSource API and functionality you could implement.

I’ve gotten a few questions (including a great comment) about needing to install Silverlight under offline or administrative-restricted environments.  There are two ways you can install this.

First, you’ll still need the Silverlight Tools for Visual Studio installer.  Next, make sure you download the Silverlight Developer Runtime (Windows).  There is a Mac runtime for developers as well, but if you are wanting to install the developer tools for Visual Studio offline, I’m guessing you are on Windows :-).

Okay, here’s the two options.  These really should only be done if you need an offline install experience.  If you don’t, let the installer do the work it needs please.  These instructions are for RC0 runtime at this time only. UPDATE: These also work for RTW.

Option 1 – Extract and Paste

Open a command-line window and navigate to where you downloaded the silverlight_tools.exe (Silverlight Tools for Visual Studio) file.  Run this command:

   1: silverlight_tools.exe /x

This should bring up a window like this:

Choose a location where you want the installer files to be extracted.  Make note of that path :-).  Now take the Silverlight_Developer.exe file you downloaded (Silverlight Developer Runtime) and put it in the folder where you just extracted the tools bits.

Now from the extracted folder, run SPInstaller.exe and the setup should run through installing the developer runtime and all the other required tools for development.

Option 2 – Put the Silverlight Developer Runtime in Temp

The second option still requires you to have both files, but you don’t have to extract the files from the tools installer.  It involves putting the developer runtime in your current Temp directory.  How do I know what my current temp directory is?  Again, open a command window and type:

   1: cd %TEMP%

This should navigate you your current Temp directory.  Now that you are in this directory, create a directory called “Silverlight Tools RTW” – you can use your command window to do this by typing:

   1: mkdir "Silverlight Tools RTW"

Now copy the Silverlight_Developer.exe file into that newly created folder and run the silverlight_tools.exe installer file.  This should get you the developer runtime installed and then the remaining tools.

I hope this helps some get over any admin/offline hump you may be experiencing.

One area where Silverlight can plat an interesting role for your web applications is wherever file uploading to your server needs to be done.  This may sound odd to think of it that way, but if you’ve ever done file upload in web apps (for larger sizes, chunking, etc.) sometimes it is no fun and involves a lot of Javascript.  There is a video demonstrating on how you can do file upload with Silverlight 2 and also helps demonstrate the OpenFileDialog API within the runtime.

I remember seeing a multi-file uploader that Jose Farado had started back in Silverlight 1.1 days.  It followed the UI inspiration from the Flickr picture uploader and I really liked it.  Jose has been real busy since then and hasn’t had much time to update his older 1.1 samples to Silverlight 2, but a few others have started to emerge.

Over at the Silverlight community gallery, you can find a bunch of user-submitted content that includes full solutions, samples, helpful tips, etc.  Right now you can find pointers to 2 solutions implementing multi-file uploading using Silverlight as a UI and controller in the process.

One is from Michiel Post and the other is from InetSolution, Inc.  Both of them provide similar functionality.  (NOTE: none provide full source code at the moment or have alluded that they will.)  One thing that the team at InetSolution did after receiving some inquiries about their work was to write a bit about it in an ‘under the hood’ post about their effort so far.

UPDATE: Michiel Post has now updated the control and provided source on Codeplex.

I’d love to see either of these adapt the UI that Jose had implemented…but in the meantime, check them out!

Today we released Silverlight 2 RC0.  This release is for a very specific purpose and although the information will likely be repeated, I wanted to try to help answer a few questions.

What is this release?

RC0 is a developer release only!  The intent of providing these bits is to provide developers with ample time to have access to the release candidate runtime/controls for Silverlight with the primary goal of making sure that developers with Silverlight 2 Beta 2 applications that are live today prepare for the release of Silverlight 2.

What should a developer do?

If you have a Silverlight 2 Beta 2 application that is out there today, you should use this RC0 build to port/stage your application in a test environment to this RC0 build and test to make any required changes based on the breaking changes from Beta 2 to RC0.

Why should I care?

Because your Silverlight 2 Beta 2 applications will not work on the release of Silverlight 2.  If you have applications today, you want to make sure that your application will work and that is why we’re providing this RC0 build for developers now.

I’ve made my changes and it works, should I deploy it now?

NO!  This is a developer release only.  What does that mean? That means that there is no end-user installable runtime that is released, only the developer runtime with the developer tools.  If you deploy an RC0 application into the wild your users will be greeted with unfriendly install messages taking them to bits for Beta 2, making them confused.  You should, however, deploy to your test environments for your test team(s) to check out your application.

So why am I doing this again then?

Sorry to be repetitive, but this is for developers.  Again, the goal is to give developers who have Beta 2 applications ample time to port/stage and test their applications.  You want to do this to be ready so that when Silverlight 2 releases, your app will be ready and you can flip the switch on your bits.

Will my end users be auto updated to RC0?

No, end users who have either Silverlight 1.0 or Silverlight 2 Beta 2 installed will not be automatically updated to RC0.  When Silverlight 2 releases, they will be notified of a new version for the release version.

So how will I know what may break?

We’ve created a breaking changes document that provides the breaking changes between Beta 2 and RC0.  It is available for you to download and we recommend you use this as your guide and first point of attack when troubleshooting porting your application.  The breaking changes document is located here.

As an example, here’s one that I think is so simple, but might have some banging their heads when their users complain they are still being asked to install Silverlight.  In the Beta 2 builds, if you use the <object> instantiation method, your code may look something like this:

   1: <object data="data:application/x-silverlight," type="application/x-silverlight-2-b2" width="100%" height="100%">

   2:     <param name="source" value="ClientBin/XMLFile.xap"/>

   3:     <param name="onerror" value="onSilverlightError" />

   4:     <param name="background" value="white" />

   5:     

   6:     <a href="http://go.microsoft.com/fwlink/?LinkID=115261" style="text-decoration: none;">

   7:         <img src="http://go.microsoft.com/fwlink/?LinkId=108181" alt="Get Microsoft Silverlight" style="border-style: none"/>

   8:     </a>

   9: </object>

In RC0 (and release) you’ll want to change it to this:

   1: <object data="data:application/x-silverlight," type="application/x-silverlight-2" width="100%" height="100%">

   2:     <param name="source" value="ClientBin/XMLFile.xap"/>

   3:     <param name="onerror" value="onSilverlightError" />

   4:     <param name="background" value="white" />

   5:     

   6:     <a href="http://go.microsoft.com/fwlink/?LinkID=124807" style="text-decoration: none;">

   7:         <img src="http://go.microsoft.com/fwlink/?LinkId=108181" alt="Get Microsoft Silverlight" style="border-style: none"/>

   8:     </a>

   9: </object>

Notice the type attribute in the <object> tag changes from application/x-silverlight-2-b2 to application/x-silverlight-2.  Please note this is the plugin application type only and not to be confused with the server-side MIME type mapping (which should be .XAP mapping to application/x-silverlight-app).

Also notice the correct link to the “fwlink” to the runtime.  When Silverlight releases you’ll be sure in your custom install experience (please don’t use the default) you’ll want to point to the right link.

Ok, I’m convinced, what do I need to do?

Here’s what I’d do if I had a beta 2 application:

• Re-read the above to make sure I understand the intent of this release fully.
• Download the Silverlight Tools for Visual Studio 2008 (RC0) – this will give you the VS project templates, the VS updates required, the RC0 developer runtime and the SDk documents.
• Download the Expression Blend 2 Service Pack 1 Preview – this build of Blend is targeted against the release bits of Silverlight and will help you in porting your application.
• Make sure you have a backup of your project (or set a version/tag/branch in your source control) so you can rollback if needed.
• Open your Silverlight project using the updated tools.  You’ll see a note about the project needing to be upgraded.
• Compile/run your application and pay attention to any warnings/errors that the compiler/Visual Studio spit out.
• Compare/contrast any warnings/errors with the breaking changes document and modify if needed.
• Put your application in a test environment only for your developers/internal testers to mess around with.  Do not deploy your application to your customers yet!
• Rinse.  Repeat.  The testing/changing cycle that is.

This should get you going rather quickly.  If you experience issues, use the appropriate feedback channels that you’ve already established (i.e., if you are working with someone at Microsoft or have a contact).  Please be sure to consult the breaking changes document first though.

Allow me to comment about breaking changes.  I know that as a developer this can add work for you…ah the joys of being an early adopter!  Breaking changes in beta to release products can be a good thing if it helps bring compatibility in frameworks and if it makes for an easier or more logical API.

Okay, so we do all this prep work, when is Silverlight 2 releasing?

Ah, the magic question.  While we aren’t providing any dates right now, we are still committing to shipping Silverlight this year.  We are providing this release now to ensure you as a developer can stage/test your Beta 2 applications and be ready!  If you don’t have any applications that are running now (live) on Beta 2 but have been working on one, then you’ll want to start with RC0 as well so that you minimize the work you have to do when you go live.

Other goodness

The ADO.NET Data Services (the artist formerly known as “Astoria”) bits are also updated in RC0 SDK/Tools.  The bits that were provided as a stop gap are now a part of the RC0 bits.

Need the Mac developer runtime for testing?  You can get that here.  Also keep in mind this is a developer build as well.

What’s new you say?  Well not a ton (as we’ve been saying) but you should see a ProgressBar, PasswordBox and ComboBox in there now!  In addition to the new controls, all the controls were updated with new skin templates.  Also the RC0 bits allow you to enable HTTP hosted applications to call secure services (policy file required), which I know people have been wanting.  Wondering about stuff that Shawn mentioned?  Well you shouldn’t have expected them here for 2 reasons.  First, they aren’t going to be a part of the core runtime.  Second he mentioned that they are working toward a preview release for PDC (end of October).  So be on the lookout for that work!

I hope this helps!  Again, this information is also linked here and you can see some more notes from ScottGu here.