If you are migrating Silverlight applications that were created for the Silverlight 2 Beta 2 release or earlier to the final release of Silverlight 2, you must get the newest Silverlight 2 Tools for Visual Studio 2008 and recompile your project(s).

1. Get the newest version of Silverlight 2 Tools for Visual Studio 2008. You can get these tools from the SDK or online at Getting Started. You may have to uninstall any old tools before doing this installation.

2. Open your old project (for example, .csproj file). A dialog box will come up notifying you that your project was created by using an older version of Silverlight tools and asks you if you want to upgrade your project. Click the Yes button.

3. Debug. Many of the breaking changes you are likely to encounter can be found in this document.

Who Is Affected: Applications that use ContentPresenter or objects derived from ContentPresenter.

Summary

Because ContentPresenter now derives from FrameworkElement, the following properties are no longer exposed by ContentPresenter:

• Background

• BorderBrush

• BorderThickness

• DefaultStyleKey

• FontFamily

• FontSize

• FontStretch

• FontStyle

• FontWeight

• Foreground

• HorizontalContentAlignment

• IsEnabled

• IsTabStop

• Padding

• TabIndex

• TabNavigation

• Template

• VerticalContentAlignment

Fix Required

Remove all these obsolete properties from your ContentPresenter objects, which will likely require that you re-work some of your code to restore your previous UI rendering.

Who Is Affected: All content using layout might be rendered slightly differently because layout no longer causes elements to be rendered at subpixel locations.

Summary

The layout system in Silverlight has been modified to round final measure and arrange values to integers when positioning elements on the screen ("pixel snapping"). The result is crisper lines, more consistent rendering look, and fewer rendering artifacts.

By default, layout rounding will be on, but there is a new inherited property on UIElement called UseLayoutRounding that can be set to false if the old layout behavior is desired.

Note:
It is possible that this change will affect how your animations render, in which case you might want to set UseLayoutRounding to false.

Note:
This change does not affect transforms. If you apply a transform to an element, it may still be rendered at a subpixel location.

Who Is Affected: Anyone serving Silverlight 2 applications from cross domain:

• Via a Web server that is not IIS7

• Via a Web server where the MIME type for .XAP files is incorrectly configured

Summary/Fix Required

When the XAP is served from a different domain than the host HTML page, Silverlight will validate that the MIME type (Content-Type response header) returned on the HTTP response is application/x-silverlight-app.

Apache (and perhaps other servers) typically serve unrecognized content as text/plain, and therefore will be affected by this change. You are required to add an entry for the Silverlight XAP MIME type to your .htaccess file. For example, AddType application/x-silverlight-app xap.

Note:
IIS7 included the correct MIME type configurations for Silverlight XAPs. No action is required if you are using IIS7.

Who Is Affected: Silverlight 2 applications that use HttpWebRequest.

Summary/Fix Required

For HttpWebRequest:

Before:

• Some security exceptions (for example, cross-scheme violations) were being raised in HttpWebRequest.BeingGetResponse()

• All other request error conditions were being returned as 404s.

Now:

• Error conditions are now raised as exceptions in HttpRequest.EndGetResponse().

  • Request security errors (for example, requests not allowed by cross domain policy) raise SecurityExceptions

  • Non-successful requests (for example, those that returned 404 error messages) raise WebExceptions. The WebException.Response is set to HttpStatusCode.NotFound. This is compatible with the desktop.

What Is Affected: Silverlight 2 Beta 1 or Beta 2 applications (not Silverlight 1.0 applications) that reference fonts (or collections of fonts) by way of the URI syntax in the Control.FontFamily, TextBlock.FontFamily or Glyphs.FontUri attributes and where the fonts are not embedded in the assembly (.dll) of the control or application.

Fix Required

You can specify a font (or in some cases a zip of fonts) in URI format through the Control.FontFamily, TextBlock.FontFamily, and the Glyphs.FontUri attributes. If you are, you will have to make sure that your font is marked as a "resource" in the project system.

What Is Affected: Silverlight 2 Beta 2 applications that use the HTML bridge HtmlElementCollection. The type has been replaced with a new type: ScriptObjectCollection.

Summary

The System.Windows.Browser.HtmlElementCollection type was changed to ScriptObjectCollection. All previous references to HtmlElement on the collection have been changed to instead reference ScriptObject. Other areas of the HTML bridge that previously used HtmlElementCollection (that is HtmlElement.Children) have been switched to instead return a ScriptObjectCollection. Note that if you retrieve an item from the new ScriptObjectCollection that is actually an HtmlElement, you can still cast the return value back to an HtmlElement.

The specific benefit from this change is that across all browsers you can now access both element and non-element DOM nodes that are contained in a node collection. We made this change because there is no consistent cross-browser implementation of an HtmlElement-specific collection type.

Fix Required

Change existing references to HtmlElementCollection to ScriptObjectCollection. If your existing code was working with HtmlElement return values, you must explicitly cast the items returned from a ScriptObjectCollection to an HtmlElement. Since the collection type is now ScriptObjectCollection it is likely that on different browsers the ordinality of the resulting collection will also change. Any code that was relying on fixed offsets into the collection may have to be changed to account for non-element nodes (for example, text nodes such as whitespace, etc…) in the collection.

Beta 2

HtmlElement myHtmlElement = someOtherHtmlElement.Children[5];

Release

HtmlElement myHtmlElement = (HtmlElement)someOtherHtmlElement.Children[5]; //assuming the desired element is still at offset 5

What Is Affected: Silverlight 1.0 and 2.0 applications that change properties on active animations.

Summary

When you change one of the properties in the following list on an active Storyboard, an exception is raised at runtime with this message: “Operation is not valid on an active Animation or Storyboard. Root Storyboard must be stopped first."

The list of properties that cannot be modified on an active animation or Storyboard are in the following list:

Who Is Affected: Anyone who uses the extended controls (Calendar, DatePicker, TabControl and GridSplitter).

Fix Required

Change all references from System.Controls.Extended to System.Windows.Controls and recompile your application.

Who Is Affected: Silverlight 2 applications that use VisualStateManager.

Summary

VisualTransition.Duration has changed to VisualTransition.GeneratedDuration. This value will now only affect the generated transitions, and not the VisualTransition.Storyboard.

Example:

In the XAML shown here, the VSM generated animations for the Pressed-> Normal transition will be created with 1 second durations. The explicit transition Storyboard with its blue ColorAnimation will still be 2 seconds.

<vsm:VisualStateGroup x:Name="CommonStateGroup">
   ...
   <vsm:VisualStateGroup.Transitions>
      ...
      <vsm:VisualTransition From="Pressed" To="Normal" GeneratedDuration="0:0:1">
         <Storyboard>
             <ColorAnimation Storyboard.TargetName="MainRect"  Duration="0:0:2"
                             Storyboard.TargetProperty="Fill" SpeedRatio="2" To="Blue"/>
        </Storyboard>
      </vsm:VisualTransition>
   </vsm:VisualStateGroup.Transitions>

</vsm:VisualStateGroup>

VisualStateManager.CustomVisualStateManager should be set on the root visual of the ControlTemplate or UserControl, not the Control/UserControl itself. In the following example, the custom visual state manager is set on the Grid, the ControlTemplate’s root visual.

<ControlTemplate  TargetType="local:CheckBox">
  <Grid x:Name="RootElement" HorizontalAlignment="Center" 
    VerticalAlignment="Center" Background="Transparent">

    <vsm:VisualStateManager.CustomVisualStateManager>
      <local:MyVisualStateManager>
    </vsm:VisualStateManager.CustomVisualStateManager>

  ...

  </Grid> 
</ControlTemplate>

Who Is Affected: If you previously have been doing operations in the KeyDown event that could cause reentrancy into the Silverlight control, such as calling into the HtmlPage.Window.Alert function, this will no longer be supported.

Summary

We switched over our keyboard handling for character input to use the concept of WM_CHAR windows message. This is used for TextBox/PasswordBox text entry to enable scenarios such as entering AltGr keystrokes. In order for us to do this the KeyDown event had to be sent synchronously for managed code.

Who Is Affected: Silverlight 2 Beta 2 Applications that use MeasureOverride and ArrangeOverride on Canvas.

Summary

MeasureOverride and ArrangeOverride virtual methods on Canvas are sealed. These methods were already sealed for Grid and StackPanel. Any custom panel that requires its own layout logic should subclass Panel.

Who Is Affected: Silverlight 2 managed code referencing the UriTypeConverter class.

Fix Required

UriTypeConverter was moved from System.Windows.Controls.dll to System.dll where it resides on the desktop framework. Applications that reference it must be recompiled.

Who Is Affected: Those using HtmlPage.UnregisterScriptableObject.

Fix Required

Alternative to using HtmlPage.UnregisterScriptableObject, developers can now re-use the same script registration key for RegisterScriptableObject. This enables developers to change the underlying managed object associated with a scriptable entry point.

Who Is Affected: Silverlight 2 managed code referencing the RenderingEventArgs class.

Summary

The following changes have been made to class RenderingEventArgs

• RenderingEventArgs is moved from System.Windows to System.Windows.Media

• RenderingEventArgs.ctor() is now internal

• System.Windows.RenderingEventHandler has been removed.

Who Is Affected: Silverlight 2 managed code that uses either the ContentPresenter or ContentControl classes.

Summary

The following properties were removed from ContentPresenter and ContentControl.

• TextAlignment

• TextDecorations

• TextWrapping

Who Is Affected: Silverlight 2 applications which use the OpenFileDialog.

Summary

• The System.Windows.FileDialogFileInfo type is being removed. Its functionality is now being exposed through its base System.IO.FileInfo type to transparent code within the Silverlight sandbox.

• System.Windows.Controls.OpenFileDialog has a couple properties which consume and expose FileDialogFileInfo. They are being modified to return FileInfo type.

• In addition, the property names SelectedFile and SelectedFiles are also being changed to File and Files.

Fix Required

Beta 2

// Returns a File object for the selected file. If multiple files are selected, returns the first selected file
public FileDialogFileInfo SelectedFile { get; }

// Returns a collection of File objects for the selected files
public IEnumerable<FileDialogFileInfo> SelectedFiles { get; }

Release

// Returns a File object for the selected file. If multiple files are
// selected, returns the first selected file
public FileInfo File { get; }

// Returns a collection of File objects for the selected files
public IEnumerable<FileInfo> Files { get; }

Sample usage of OpenFileDialog with this change:

openFileDialog = new System.Windows.Controls.OpenFileDialog();
openFileDialog.Multiselect = false;
openFileDialog.Filter = "Text Files (*.txt)|*.txt|All files (*.*)|*.*";

bool? retval = ofd.ShowDialog();
if (retval != null && retval == true) {

    // Get the filename
    string filename = openFileDialog.File.Name;
    // Open the file
    System.IO.Stream filestream = openFileDialog.File.OpenRead();

    // Do something with the filestream

    // Close it
}

Who Is Affected: Only Silverlight 2 applications that use this combination of features:

• XAP deployed on a different domain than the host HTML page, and

• with application manifest (AppManifest.xaml) specifying ExternalCallersFromCrossDomain=”FullAccess” on the root element are affected.

Summary

The ability for arbitrary scripts to walk the element tree, register for and get notified on events, and use the Silverlight 1.0 Downloader from script has been curtailed in a cross-domain application deployment scenario. The application manifest previously supported the ability for application author to designate the ExternalCallersFromCrossDomain attribute that has the values NoAccess (default in cross-domain), ScriptableOnly and FullAccess. Support for the FullAccess option has been removed.

Many of the purposes you would have relied on the FullAccess option can now be fulfilled through the Scriptable object feature, with minor additional work on your part.

Summary and Fix

Virtual methods Add, Contains, Indexof, Insert, Remove, get_Item, set_Item are no longer declared on the following collections:

• ColorKeyFrameCollection.

• DoubleKeyFrameCollection

• ObjectKeyFrameCollection

• PointKeyFrameCollection

• PointKeyFrameCollection

• StrokeCollection

Who Is Affected: Silverlight 2 applications that use HttpWebRequest.BeginGetResponse().

Summary

You must close the request stream on an HttpWebRequest before calling BeginGetResponse(). Previously BeginGetResponse() would close an open request stream.

Who Is Affected: Code that uses System.Windows.Browser.HtmlWindow and that expects two HtmlWindow references pointing at the same DOM window to evaluate to true will now return false when it is running on Safari 2 or Safari 3 on Mac.

Summary

For example:

• Create a page with one iframe

• Use the bridge to retrieve two references to the iframe:

• HtmlWindow one = document.GetElementById(“myIframe”);

• HtmlWindow two = document.GetElementById(“myIframe”);

• With the change the following comparison will now return false on Safari 2/3 Mac:

• bool areEqual = (one == two);

Fix Needed

If you were depending on the Address property, you can work around this breaking change in the following way:

Beta 2

void Callback(object sender, DownloadStringCompletedEventArgs args)
{
    DebugPrint(args.Address.ToString());
}

void MakeCall(Uri uri, object userState)
{
    webClient.DownloadStringAsync(uri, userState);
}

Release

class DownloadState
{
    public DownloadState() {}
    public Uri Address;
    public object ActualUserState;
}

void Callback(object sender, DownloadStringCompletedEventArgs args)
{
    DownloadState userState = (DownloadState)args.UserState;

    DebugPrint(userState.Address.ToString());
}

void MakeCall(Uri uri, object userState)
{
    Uri absoluteUri = uri;
    if (absoluteUri.IsAbsoluteUri == false)
    {
        absoluteUri = new Uri(new Uri(webClient.BaseAddress), absoluteUri);
    }

    DownloadState downloadState = new DownloadState();
    downloadState.Address = absoluteUri;
    downloadState.ActualUserState = userState;

    webClient.DownloadStringAsync(uri, downloadState);
}

Summary

You can no longer create the objects in the following list because their associated constructors have been made internal:

• SizeChangedEventArgs

• TextChangedEventArgs

• DownloadProgressEventArgs

• ExceptionRoutedEventArgs

• KeyEventArgs

• MouseButtonEventArgs

• MouseEventArgs

• StartupEventArgs

• Expression

• GeneralTransform

• Geometry

• ImageSource

• PathSegment

• SetterBase

• Transform

• BindingExpressionBase

• InputMethod

Summary

In the methods/constructors shown that are shown here, we will no longer be checking for null arguments. As a result, the usage of null arguments will cause a NullReferenceException. In previous builds of Silverlight, use of a null argument would cause an ArgumentNullException being thrown. There is no change in functionality, just the type of exception that is being thrown.

• 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 method

Summary

Certain classes that were defined by the Silverlight runtime were creatable in XAML, even though they did not have an available constructor. With this change, you can no longer instantiate those classes in XAML.

These classes (which only have internal constructors) can no longer be created in XAML:

• TriggerCollection

• InlineCollection

• RowDefinitionCollection

• ColumnDefinitionCollection

• RoutedEventArgs

• MouseButtonEventArgs

• KeyEventArgs

• ErrorEventArgs

• UIElementCollection

• Downloader

• InternalWebRequest

• MultiScaleSubImageCollection

• MediaAttribute

• MediaAttributeCollection

• ExceptionRoutedEventArgs

• DownloadProgressEventArgs

• StartupEventArgs

• TextBoxBase

• TextBoxView

• TextChangedEventArgs

• RuntimeHostEventArgs

• SizeChangedEventArgs

• RenderingEventArgs

• ItemCollection

• CorePropertyChangedEventArgs

• IsEnabledChangedEventArgs

• TypeProxy

• ManagedObjectReference

• AutomationPropertiesEnum

• DependencyPropertyProxy

Summary

In earlier versions of Silverlight, when media failed because a media file was not available, a MediaFailed event was fired but if the MediaFailed event was not handled by the developer, the end user would not be notified of the failure. Now when a handler is not hooked up to the MediaFailed event, the error bubbles up to the default OnError handler of the plug-in and AG_E_UNKNOWN_ERROR is displayed to the user.

Fix Required

Attach the MediaFailed event to your MediaElement objects and handle errors as appropriate.

Summary

The platform now looks for the generic.xaml resource dictionary as an assembly resource in the "themes" directory instead of the root directory.

Fix Required

Move your generic.xaml resource underneath the "themes" folder under ControlLib.

Who Is Affected: This will affect anyone using the HTTP Polling Duplex channel.

Summary

• PollTimeout setting on the server side (PollingDuplexHttpBinding and PollingDuplexBindingElement) has been renamed to ServerPollTimeout

• PollTimeout setting on the PollingDuplexBindingElement (client-side) has been renamed to ClientPollTimeout.

• PollTimeout setting on the PollingDuplexHttpBinding (client-side) has been cut. In most scenarios, you should not have to change this. If a change is necessary, it can be achieved through the ClientPollTimeout on the PollingDuplexBindingElement.

• Client-side support has been cut from the non-Silverlight (server-side) polling duplex assembly (that is BuildChannelFactory will throw a NotSupportedException). In the original release version, the client-side for polling duplex must be Silverlight (and the server side must be the regular .NET Framework, but this restriction was already in place in Beta 2).

• Default timeouts have been changed for the Duplex channel. For most common scenarios, the new out-of-the-box defaults should be appropriate and you do not have to change them.

• An error (404) on a polling request will cause the duplex channel to fault.

• Various invalid messages used to be ignored by the Duplex stack but will now be rejected.

• If any HTTP error (404,500, and so on) is encountered during a SOAP call, a CommunicationException is now thrown instead of a ProtocolException.

Who Is Affected: Applications that host Silverlight 2 natively through its COM APIs.

Summary

• The following splash screen related properties added to IXcpControl interface are being broken out and being moved to a new IXcpControl2 interface:

• get_OnSourceDownloadComplete

• get_OnSourceDownloadProgressChanged

• get_SplashScreenSource

• put_OnSourceDownloadComplete

• put_OnSourceDownloadProgressChanged

• put_SplashScreenSource

In addition, the LoadRuntime function is also being moved to IXcpControl2.

Summary

The supported cross-domain policy files (crossdomain.xml and clientaccesspolicy.xml) are no longer required to explicitly allow the Content-Type request header. The Content-Type header is always settable on a POST xdomain request, as long as the request itself is allowed by a cross-domain policy file.

In addition, the LoadRuntime function has moved to IXcpControl2.

Fix Required

Previously, you needed to specify Content-Type in the headers allow list. Now, Content-Type is always allowed, so the "Content-Type" attribute value is no longer required just for setting the Content-Type (see the following examples).

clientaccesspolicy.xml

The following is the old version that explicitly listed Content-Type as settable. (This file still works in the Silverlight 2 final release.)

<?xml version="1.0"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="Content-Type, SOAPAction">
        <domain uri="*"/>
      </allow-from>
        <grant-to>
          <resource include-subpaths="true" path="/"/>
        </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

The following is the new version that still allows Content-Type to be set.

<?xml version="1.0"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="SOAPAction">
        <domain uri="*"/>
      </allow-from>
      <grant-to>
        <resource include-subpaths="true" path="/"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

crossdomain.xml

The following is the old version that explicitly listed Content-Type as settable. (This file still works in the Silverlight 2 final release.)

<?xml version="1.0"?>
<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd">
    <allow-access-from domain="* " />
    <allow-http-request-headers-from domain="* " headers="Content-Type, SOAPAction" secure="true" />
</cross-domain-policy>

The following is the new version that still allows Content-Type to be set.

<?xml version="1.0"?>
<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd">
    <allow-access-from domain="* " />
    <allow-http-request-headers-from domain="* " headers="SOAPAction" secure="true" />
</cross-domain-policy>

Who Is Affected: Code that bypasses the delegate type check in Delegate..::.Combine by calling MulticastDelegate..::.CombineImpl directly.

Fix Required

If you want to combine two delegate objects, they should be of the exact same delegate type.

The following are breaking changes related to DataGrid .

<data:DataGridTextColumn DisplayMemberBinding=”{Binding FirstName}” />

<data:DataGridTextColumn Binding=”{Binding FirstName}” />

System.Windows.Controls.IEditableObject

System.ComponentModel.IEditableObject

void SelectionChanged(object sender, EventArgs e)
{
}

void SelectionChanged(object sender, SelectionChangedEventArgs e)
{
}

dataGrid.HeadersVisibility = DataGridHeaders.Column;

dataGrid.HeadersVisibility = DataGridHeadersVisibility.Column;

string name = e.Property.Name;
Type type = e.Property.Type;

string name = e.PropertyName;
Type type = e.PropertyType;

protected override FrameworkElement GenerateEditingElement(object dataItem)
{
}
protected override FrameworkElement GenerateElement(object dataItem)
{}

protected override FrameworkElement GenerateEditingElement(DataGridCell cell, object dataItem)
{
}
protected override FrameworkElement GenerateElement(DataGridCell cell, object dataItem)
{}

public object DragIndicatorContent { get; set}
public FrameworkElement DropLocationIndicator { get; set}