Silverlight 2 Release Candidate
Last night a release candidate for the Silverlight 2 developer runtime and tools went live. This release candidate lets developers update their applications before the end user runtime is released in a few weeks. The release candidate is feature complete. There are some breaking changes from the last beta release, most of which are the removal of scattered methods and constructors to clean up the classes that were ported from the desktop framework. Here are the changes that may impact WCF developers.
The MIME type of Silverlight applications should now be the final release version application/x-silverlight-2.
Cross domain hosts of Silverlight must set the right MIME type for XAP (application/x-silverlight-app).
Some exceptions that were previously thrown in HttpWebRequest.BeginGetResponse() are now thrown in HttpWebRequest.EndGetResponse(). This may cause a similar shift in timing when using the asynchronous WCF APIs to send HTTP messages.
Many of the XML APIs will now throw NullReferenceException where they used to throw ArgumentNullException. This may cause a similar change with messages and serialization when dealing with bad data.
Cross domain policy files no longer need to explicitly allow the Content-Type request header. The Content-Type header is always settable on cross domain POST requests.
There are some more detailed changes for the HTTP polling duplex channel.
- The PollTimeout setting has been split into ServerPollTimeout and ClientPollTimeout.
You're no longer able to create an HTTP polling duplex client on the full desktop framework.
- Default timeouts have been changed to cover most common scenarios.
- A 404 error on a polling request now causes the duplex channel to fault.
- Various invalid messages that used to be ignored by the duplex channel are now rejected.
- An HTTP error during an application call now results in a CommunicationException instead of a ProtocolException.
Comments
Anonymous
September 28, 2008
The RC version is out and ready for use. Read Scott's post & Nicholas for what's out thereAnonymous
September 28, 2008
What is the rationale for the change from ArgumentNullException to NullReferenceException? Most guidelines I've seen (including the Framework Design Guidelines) say to always check the arguments passed to public methods and throw ArgumentNullException if one of them is null when it shouldn't be. In fact the Framework Design Guidelines explicitly call out NullReferenceException as one of the four exception types that should never be explicitly or implicitly thrown from a publicly callable member. I've often seen NullReferenceException treated as a "critical exception" (along with other types like StackOverflowException, ThreadAbortException, ExecutionEngineException, etc.) which is handled specially (such as failing fast or not suppressing it when other exceptions normally would be suppressed). Both of these factors would seem to suggest that this is not a good change…Anonymous
September 29, 2008
Hi Kevin, The desktop framework today throws NullReferenceException in these cases. The Silverlight beta changed the behavior to match the guidelines. It was then decided that it was better to keep the existing desktop behavior so that code would be portable between the two. Here's an exact list of methods affected: XmlReader.IsName method XmlReader constructor XmlReader.MoveToAttribute method XmlReader.IsNameToken method XmlNamespaceManager constructor XmlReader.Nametable.Add method XmlReader.Nametable.Get method XmlCharCheckingWriter.WriteQualifiedName method XmlCharCheckingWriter.WriteDocType method XmlConvert.ToBoolean method XmlConvert.ToDouble method XmlConvert.ToSingle method XmlConvert.ToDateTime methodAnonymous
September 30, 2008
In that case, this was definitely a good change. Consistency and compatibility between the desktop framework and Silverlight is very important. Thanks for the explanation!Anonymous
January 15, 2009
The RC version is out and ready for use. Read Scott's post & Nicholas for what's out there