• Article

Ensuring That Your Silverlight Applications Work with Silverlight 4

Microsoft Silverlight will reach end of support after October 2021. Learn more.

Several changes have been made to the Silverlight runtime and the Silverlight Tools between Silverlight 3 and Silverlight 4. For these changes, the following principles apply:

  • Most Silverlight 3 applications will work with Silverlight 4 without any changes.

  • When breaking changes are required, Silverlight will try to maintain support for the old behavior, as well as the new behavior, by using a quirks mode.

Nevertheless, some changes made to Silverlight components can potentially cause your older Silverlight-based applications to fail (compile time, XAML load time, or possibly design time) or to behave differently.

This topic describes the changes that were made between Silverlight 3 and Silverlight 4. This topic does not describe new features or enhancements for Silverlight 4. For information about what is new in Silverlight 4, see Silverlight Feature Introduction History Listed by Version. This topic also does not describe new behaviors in Silverlight 5. For more information, see What's New in Silverlight 5 and Silverlight Versions and Version Compatibility.

That topic assumes that you are using the Silverlight 4 tools in Visual Studio.

NoteNote:

For corrections and additions to this topic, see the Silverlight SDK blog.

This topic contains the following sections:

  • Upgrading Projects From Silverlight 3 to Silverlight 4 This section describes upgrading your Silverlight 3 projects.

  • XAML Parser Changes This section introduces the XAML parser changes in Silverlight 4.

  • Breaking Changes since Silverlight 3 This section describes changes that can potentially break applications written for Silverlight 3 that users run on the Silverlight 4 runtime, even when the application manifest targets Silverlight 3.

  • Quirks Mode Behavior This section describes where the runtime or its API include version-specific behavior differences. These behavior differences are based on which runtime version the application targets. Often, the changes represent bug fixes to Silverlight 4, but the Silverlight 3 behavior remains accessible as a specific quirks mode, which is used only when the application targets a Silverlight 3 runtime. This is done in case the logic of your application relied on the Silverlight 3 behavior.

  • Upgrade Breaking Changes This section describes changes that are relevant if you re-compile a Silverlight 3 application and intend to target Silverlight 4.

  • Breaking Changes for Silverlight 4 Beta This section describes changes that are only relevant for applications that were compiled specifically for Silverlight 4 Beta. There is no quirks mode for the Silverlight 4 Beta runtime behavior.

Upgrading Projects From Silverlight 3 to Silverlight 4

You can upgrade a project from Silverlight 3 to Silverlight 4 in Visual Studio. Just make sure to appropriately target the version of the upgrade project in the Silverlight Build Options / Target Silverlight Version section of the Visual Studio project configuration dialog. You can use the Silverlight 5 tools to upgrade a project from Silverlight 3 to Silverlight 4.

If you are upgrading a project originally composed for and targeting Silverlight 3, and now targeting Silverlight 5, you should read Ensuring That Your Silverlight Applications Work with Silverlight 5 first. Perform whatever actions are necessary to ensure that the project runs when targeting Silverlight 4. Only then should you retarget the project again for Silverlight 5. This will help isolate the compatibility issues and clarify which quirks mode (if any) is being engaged by a particular targeted runtime.

For more information, see the "Upgrade Breaking Changes" section later in this topic.

XAML Parser Changes

Silverlight 4 introduces an updated XAML parser. To maintain compatibility, the Silverlight 4 runtime includes the original Silverlight 3 XAML parser in parallel and uses it to parse XAML for any application that targets Silverlight 3. This means that if you continue to target Silverlight 3, any original XAML behavior that worked for Silverlight 3 should still work, as long as the XAML behavior does not intersect the specific breaking changes listed in the "Upgrade Breaking Changes" section. This has a net effect that is similar to a quirks mode for XAML loading.

If you are upgrading a Silverlight project that previously targeted Silverlight 3 to target Silverlight 4, changes to your XAML may be required. If you are upgrading a Silverlight 4 Beta project, changes to your XAML may be required. The Silverlight 4 Beta XAML parser behavior is largely the same as the Silverlight 3 XAML parser.

The XAML behavior differences that may impact your application's XAML are too extensive to be listed here and are instead documented in other topics. For more information, see XAML Processing Differences Between Silverlight Versions or XAML Processing Differences Between Silverlight Versions and WPF.

Breaking Changes since Silverlight 3

The changes described in this section can potentially break Silverlight 3 applications. Many of these changes are actually bug fixes. Nevertheless, if you added workarounds in your Silverlight 3 application for these bugs, it is possible that you will have to remove these workarounds for your application to work correctly when run on the Silverlight 4 runtime.

XAML Parsing AmbiguousMatchException when application property conflicts with Silverlight 4 property

The Silverlight XAML parser (specifically the side-by-side XAML parser that handles compatibility) throws an AmbiguousMatchException if you set a property in XAML, and there exist two different properties with the same simple name. This can happen if one property-name match candidate is a member of the base class and one is a member of the derived class. At the time the application was built against the Silverlight 3 core, perhaps only the application-defined property existed. However, if a later version of Silverlight (such as Silverlight 4) adds a property with the same simple name, and that property exists in the core runtime member definitions that inherit through the base class definition, the property name is ambiguous to the XAML parser.

For example, a Silverlight 3 application might derive from TextBox, and declare a new XAML-accessible property named Watermark on the custom class. In Silverlight 3, TextBox does not have a property called Watermark, so the application XAML parses in Silverlight 3 with no possibility of name ambiguity. However, the Silverlight 4 core library definition of TextBox introduces a property named Watermark, and therefore the Silverlight 3 XAML lookup process of a simple property name is ambiguous when performed against the Silverlight 4 core runtime.

This issue only affects XAML usage; using properties in code is not ambiguous in this way. The issue only exists if there is a subclass/superclass relationship between the two property-defining types. For example, a MyButton.Watermark property would not be a problem because MyButton is not a subclass of TextBox.

This issue only affects applications that were built against Silverlight 2 and Silverlight 3. Silverlight 4 applications use a parallel XAML parser that can correctly resolve this variant of name ambiguity. The same XAML parser issue exists in a true Silverlight 3 runtime; if a Silverlight 2 application defines and uses a property name that was added in Silverlight 3, an AmbiguousMatchException occurs.

The following section lists the properties that have been added in Silverlight 4 to the common base classes (DependencyObject, UIElement, FrameworkElement, Control, and Control subclasses in System.Windows.dll). Each of these represents a property name that is a name ambiguity candidate in a subclass.

Applications that encounter this issue must recompile and target using Silverlight 4; the recompiled application uses the Silverlight 4 XAML parser and can resolve correctly.

Toggling full-screen mode reruns hit testing

Toggling full-screen mode in Silverlight 4 will rerun hit testing. This is to allow controls that were under the mouse before toggling to update their MouseOver state.

When toggling full-screen mode, the mouse pointer will likely "jump" to another location because of a change in the Silverlight plug-in size. When exiting full-screen mode, the mouse pointer might be outside the plug-in. Previously, no mouse message would be raised to notify controls that the mouse pointer is no longer over the controls. In Silverlight 4, on completing the layout after toggling full-screen mode, a mouse event will be raised to rerun hit testing and allow controls to change state if necessary.

For more information, see Full-Screen Support.

Changing the DisplayMemberPath and ItemTemplate properties of ItemControl re-creates all containers

In Silverlight 3, setting the ItemTemplate and DisplayMemberPath properties of an items template, such as in the following code, had no effect after ListBox measuring was finished.

<ListBox x:Name="lb" ItemTemplate="{StaticResource lbItem}">

lb.ItemTemplate = lbItemTemplate;
lb.DisplayMemberPath = itemDisplayPath;

In Silverlight 4, this code will invalidate all realized containers and re-create them even after the containers were measured. 

Shared BitmapImage sources

When two BitmapImage controls are sharing the same BitmapImage source, and both have no explicit Width/Height set (are using natural sizing), the second Image does not render its BitmapImage in Silverlight 3. This behavior has been fixed in Silverlight 4, and both Image controls should render their content correctly.

IronPython 2.0.2 and earlier

Silverlight 4 does not work with older versions of IronPython, please upgrade to IronPython 2.0.3 or later, which can be downloaded from https://ironpython.codeplex.com/.

Microsoft.Jscript.Compiler.dll / Microsoft.Jscript.Runtime.dll

Silverlight 4 does not work with Microsoft.Jscript.Compiler.dll / Microsoft.Jscript.Runtime.dll, also known as "DLR Jscript" and sometimes "managed Jscript". The experimental DLR Jscript was last released as part of Dynamic Languages SDK 0.4.0 Alpha. This feature was cut because it was not fully functional, and no longer works. See http://dlr.codeplex.com/Thread/View.aspx?ThreadId=58121 for details. (DLR Jscript should not be confused with the more common browser-based JavaScript API for Silverlight, which continues to work)

Quirks Mode Changes

The Silverlight team wanted to fix a number of Silverlight 3 bugs in Silverlight 4. However, by fixing some of these bugs, it is possible that some existing Silverlight 3 applications would break. In order to avoid this, the Silverlight team addressed these potentially problematic changes by creating a "quirks mode" for runtime behavior. A quirks mode change is a case where the Silverlight 4 runtime will branch its behavior if the runtime detects that the application is targeting Silverlight 3. In this way, Silverlight 4 is made "bug compatible" as a runtime. However, the noted quirks mode behavior may need to be revisited if you recompile your application for Silverlight 4 (or later).

If the RuntimeVersion for your application specifies Silverlight 3, the runtime runs in quirks mode. When in quirks mode, the runtime falls back to the Silverlight 3 behavior associated with the quirks mode changes, and behaves the same in these cases as if the runtime were literally a non-upgraded Silverlight 3 runtime.

The Silverlight 4 runtime detects whether the application was designed for Silverlight 3 by using the RuntimeVersion. The RuntimeVersion is set as an attribute in the AppManifest.xaml of the XAP file:

<Deployment xmlns="https://schemas.microsoft.com/client/2007/deployment" 
            xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml" EntryPointAssembly="ElevatorSilverlight"
            EntryPointType="ElevatorSilverlight.App" 
            RuntimeVersion="3.0.31005.0">
  <Deployment.Parts>
    <AssemblyPart x:Name="ElevatorSilverlight" Source="ElevatorSilverlight.dll" />
  </Deployment.Parts>
</Deployment>

RuntimeVersion reflects the build of Silverlight that was on the developer’s computer when the application was compiled.

If you compile your application with the Silverlight 4 Tools and you specifically target Silverlight 3, you potentially invoke quirks mode, just as if you had compiled your application with the Silverlight 3 Tools.

Correct whitespace handling with Span and Containers

TextBlock in Silverlight 3 (and RichTextArea in Silverlight 4 Beta) had a bug in <Span> or <Run> composition where the whitespace in the XAML (usually for formatting) was actually being used as content. This sometimes required limiting the newlines in the XAML source and resulted in poor human readability of the XAML. This behavior is quirked for Silverlight 3, as part of the larger XAML parser behavior described in XAML Processing Differences Between Silverlight Versions.

Text containers in Silverlight 4 accept text content and create implicit runs in the object model for any "innertext" text content. This is necessary to generate whitespace between text elements separated by CRLF. For example:

<Run>Some</Run>
<Run>Text</Run>

Translates into:

<Run>Some</Run><Run> </Run><Run>Text</Run>

The conditions for trimming leading and trailing whitespace are expanded in Silverlight 4. Previously the behavior trimmed leading whitespace for implicit Run elements unless the Run is preceded by an explicit Run. The Silverlight 4 behavior trims leading whitespace unless the implicit Run is preceded by an explicit text element that is NOT a Run (for example: Span, InlineUIContainer, Hyperlink) or an explicit Run.

The Clear method of Panel calls InvalidateMeasure

In Silverlight 4, when the Clear method of a Panel items collection is invoked, there is a call to InvalidateMeasure. This will trigger a layout on the next tick. In Silverlight 3, calling Clear will continue to have no effect on the Panel layout.

VirtualizingStackPanel.MouseWheelUp and VirtualizingStackPanel.MouseWheelDown scroll by three lines

In Silverlight 3 compiled applications, the MouseWheelUp and MouseWheelDown methods will continue to scroll by one line. However in Silverlight 4 applications, these methods scroll by three lines.

ImageBrush.ImageSource returns the ImageSource object instead of the UriSource

In Silverlight 3 applications, ImageBrush.ImageSource returns the UriSource of its ImageSource (a string). This matched the original JavaScript behavior in Silverlight 1.0.

In Silverlight 4, the actual ImageSource object is returned, which could be a WriteableBitmap or a BitmapImage.

Changing the base value during an animation works as expected

In Silverlight 3, if SetValue was called on a property in the middle of an active animation, the result is just for that one tick. SetValue would properly change that value, but on the next tick of the active animation, the animation would overwrite the set value. Visually it would often appear as if nothing had happened (the change to the new value would happen so quickly that it would be unnoticeable to the user). The SetValue call did not change the base value of the animation (result of GetAnimationBaseValue). When the animation was stopped, base value returned to the value that the property had prior to the animation being started, ignoring the SetValue.

In Silverlight 4, if the value on a property changes in the middle of an active animation, the SetValue call will modify the base value of the animation. When the animation is stopped, it will use the new base value. This matches the behavior in WPF. (Note that HoldEnd animations are not necessarily affected by this change.)

ReadLocalValue returns local value when animation is in effect

In Silverlight 3, when a property is animated and animation is running, a call to ReadLocalValue returns the animated value.

In Silverlight 4, a call to ReadLocalValue will return the local value. This matches the behavior in WPF. If you want the animated value, call GetValue.

Duplicate setters in a style not invoked when they all refer to the same attached property

In Silverlight 3, it was possible to use more than one Style Setter to set the same attached property twice. Certain scenarios made use of this characteristic.

In Silverlight 4, this behavior is no longer enabled. It is not a syntax error to set the same attached property twice in Setters. However, only the LAST Setter that references the attached property is actually invoked by the Silverlight style subsystem; any other setters are a no-op. This behavior matches the WPF behavior.

Browser zoom and Content.Resized

In Silverlight 4, if an application hooks the Resized event, the view of the Silverlight content area will automatically be zoomed when the browser zoom level is changed. If a Silverlight 4 application wants to disable automatic browser zooming, the application must explicitly set the EnableAutoZoom property to false.

In Silverlight 3, it was assumed that applications that listened to Resized would handle browser zoom themselves, and would disable automatic browser zoom. Therefore the quirks mode behavior is that no zoom behavior is associated with Resized when the application targets Silverlight 3.

MEF API Changes

The following are specific changes to the Managed Extension Framework (MEF) API that are present in the Silverlight MEF components (System.ComponentModel.Composition assembly and related).

String Comparisons and CultureInfo

Certain string comparison APIs of the String and Char class use different logic for how they obtain the acting CultureInfo, depending on whether the application runs on Silverlight 3 or Silverlight 4. This applies only in the cases where an overload does not pass a specific CultureInfo. The behavior is quirked, so Silverlight 3 applications do not have to correct for the behavior. The API differences are listed in the following table.

API

Silverlight 3

Silverlight 4

EndsWith

Ordinal

CurrentCulture

IndexOf

Ordinal

CurrentCulture

LastIndexOf

Ordinal

CurrentCulture

StartsWith

Ordinal

CurrentCulture

ToLower

InvariantCulture

CurrentCulture

ToUpper

InvariantCulture

CurrentCulture

ToLower

InvariantCulture

CurrentCulture

ToUpper

InvariantCulture

CurrentCulture

ItemsControl Population from IList, IList<T>

In Silverlight 3, if you populate an ItemsControl with an IList or IList<T>, it performs the population using an enumerator. In Silverlight 4, it performs the population using a dedicated indexer (and Count).

Upgrade Breaking Changes

If you upgrade your project to target the Silverlight 4 runtime, the issues as listed in this category often need to be addressed before your application can be recompiled. You may also need to revisit your application logic, which might have been relying on a quirks mode behavior. For more information, see the previous "Quirks Mode Changes" section.

Project Changes

If you upgrade a Silverlight project that previously targeted Silverlight 3 and specifically target Silverlight 4, certain changes may be required to the project structure. Changes might also be required for files and resources that are used by the project. In some cases, this is because something was permitted as a Silverlight 3 quirk but is no longer permitted when you change the targeting to Silverlight 4.

Several types have been moved from the Silverlight SDK into the core runtime

The following types were moved from the Silverlight SDK into the core runtime as of Silverlight 4:

Old Assembly: System.Windows.Data.dll

New Assembly: System.Windows.dll

Existing Silverlight 3 applications should continue to work as before because the System.Windows.Data.dll client assembly is typically distributed in the XAP file. If you compile your application using the Silverlight 4 Tools and target Silverlight 4, the application will use the classes in the core runtime libraries.

Also, between Silverlight 4 Beta and Silverlight 4, some (but not all) the API in the System.Windows.Navigation namespace moved from System.Windows.Controls.Navigation.dll to the core System.Windows.dll. The APIs that are in System.Windows as of Silverlight 4 are: NavigatedEventHandler, NavigatingCancelEventArgs, NavigatingCancelEventHandler, NavigationEventArgs, NavigationMode.

TabControl keyboard navigation fixed

Silverlight 3

In the keyboard navigation model for TabControl, [p]ressing the UP ARROW key activated the next TabItem and pressing the DOWN ARROW key activated the previous TabItem. This has counterintuitive behavior when TabStripPlacement is set to Left or Right. In this case, pressing the UP ARROW key activated the TabItem below the currently active TabItem and pressing the DOWN ARROW key activated the TabItem above the currently active TabItem. This behavior remains in Silverlight 3 applications; TabControl is in the System.Windows.Controls.dll assembly, which is a client library that is often packaged into the XAP file.

Silverlight 4

Pressing the UP ARROW key in Silverlight 4 activates the previous TabItem (that is the one above the currently active TabItem in vertical layout mode when TabStripPlacement is set to Left or Right). Pressing the DOWN ARROW key activates the next TabItem (the one below the currently active TabItem in vertical layout mode). This is the updated behavior if you reference or distribute a Silverlight 4 System.Windows.Controls.dll assembly.

Controls and built-in MouseWheel support

In Silverlight 4, the following controls have built in MouseWheel event support:

In Silverlight 3, there is no built-in MouseWheel support.

If you upgrade applications from Silverlight 3 to Silverlight 4, you may want to remove any previous specific handling of mouse wheel events at the application level, or perhaps in the HTML DOM. This might apply any of the following controls: ListBox, TextBox, ComboBox, and ScrollViewer. For more information, see Mouse Wheel Input.

NoteNote:

There are also controls that have MouseWheel support that are not listed here because they did not exist in Silverlight 3. An example is RichTextBox. Check individual control reference pages for presence of OnMouseWheel overrides or other remarks regarding MouseWheel handling.

DataGridCell objects and automation focus when currency changes in the DataGrid

DataGridCell objects in Silverlight 4 receive automation focus when currency changes in the DataGrid, rather than focus remaining on the DataGrid itself.

Some more detail: UI Automation clients originally did not get information about the currently focused cell because DataGridCell objects are not focusable controls (attempted Focus returns false). This has not changed. DataGridCell objects are still not focusable in UI. However, for Silverlight 4 they will receive automation focus when DataGrid currency changes. When you tab into a DataGrid and use the ARROW keys to change currency for Silverlight 4, automation focus will move to the individual cell peers so that UI Automation clients can receive specific automation property information for the cells. Previously, automation focus remained on the DataGrid; this remains as the Silverlight 3 behavior, based on the Silverlight 3 System.Windows.Controls.Data.dll.

System.ServiceModel.PollingDuplex.dll assembly has been refactored

If you previously referenced the System.ServiceModel.PollingDuplex.dll assembly, after you upgrade your project to Silverlight 4, you have to manually add a reference to the System.ServiceModel.Extensions.dll extension assembly. The original assembly has been re-factored and some classes were moved to the Silverlight 4assembly.

Breaking Changes since Silverlight 4 Beta

If you created Silverlight 4 Beta applications, there have been a number of breaking changes between Silverlight 4 Beta and Silverlight 4, which are described in the following sections.

RichTextArea has been renamed to RichTextBox

RichTextArea has been renamed to RichTextBox. The CLR namespace and assembly location remain the same.

Changes to DRM API

A few DRM-related API were changed since Silverlight 4 Beta.

BEFORE

public class DomainAcquirer 
{
  public void DomainJoinAsyncCancel();
  public void DomainLeaveAsyncCancel(); 
  public event EventHandler<DomainOperationCompletedEventArgs> DomainOperationCompleted; 
}
public class LicenseAcquirer 
{
  public void AcquireLicenseAsyncCancel();
  public string CustomData;
}
public class MediaLicense
{
  public DateTime ExpirationDate;
}
public enum ContentKeyType
{
  AES128Bit,
  Cocktail
}

AFTER

public class DomainAcquirer 
{
  public void CancelAsync();
  public event EventHandler<DomainJoinCompletedEventArgs> DomainJoinCompleted; 
  public event EventHandler<DomainLeaveCompletedEventArgs> DomainLeaveCompleted; 
}
public class LicenseAcquirer
{
  public void CancelAsync();
  public string ChallengeCustomData;
}
public class MediaLicense
{
  public Nullable<DateTimeOffset> ExpirationDate;
}
public enum ContentKeyType
{
  Aes128Bit,
  Cocktail
}

TextSelection.SetPropertyValue has been renamed to TextSelection.ApplyPropertyValue

If you have code related to RichTextArea/RichTextBox that formatted selected text using TextSelection.SetPropertyValue, you must change this code to call TextSelection.ApplyPropertyValue.

INotifyDataErrorInfo and DataErrorsChangedEventArgs moved to System.Windows.dll

INotifyDataErrorInfo and DataErrorsChangedEventArgs were added in Silverlight 4 Beta. These types have moved from System.dll to System.Windows.dll in Silverlight 4. You must recompile your project if you use these types, and may need to adjust your reference assemblies.

WebBrowser.ScriptNotify Signature Change

public event NotifyEventHandler ScriptNotify;

changed to:

public event EventHandler<NotifyEventArgs> ScriptNotify;

Also, WebBrowser.LoadCompleted in Silverlight 4 uses a more specific delegate: LoadCompletedEventHandler. You could continue to use an EventHandler and your application would still compile, but applications may want to upgrade in order to receive the NavigationEventArgs event data.

NotificationWindow API Change

In the NotificationWindow API:

public bool Visible { get; }
public event EventHandler<EventArgs> Closed;

changed to:

public Visibility Visibility { get; }
public event EventHandler Closed;

Webcam and output protection API changes

There have been a number of API changes related to webcam and output protection.

  • Collections for the audio/video capture devices as well as supported formats return an immutable collection in the form of ReadOnlyCollection<T>. This affects any call to GetAvailableAudioCaptureDevices, GetAvailableVideoCaptureDevices, or VideoCaptureDevice methods.

  • Connectors is renamed VideoOutputConnectors and the collection returned is immutable: ReadOnlyCollection<VideoOutputConnector>.

  • Capitalization was changed on several enumerations:

    VGA -> Vga
DVI -> Dvi
HDMI -> Hdmi
LVDS -> Lvds
SDI -> Sdi
UDIExternal -> UdiExternal
UDIInternal -> UdiInternal

  • CanEnableHDCP renamed CanEnableHdcp and CanEnableCGMSA renamed CanEnableCgmsa.

  • VideoFormat.Height renamed VideoFormat.PixelHeight. VideoFormat.Width renamed VideoFormat.PixelWidth.

  • WaveFormatType.PCM renamed WaveFormatType.Pcm.

  • ContentKeyType.AES128Bit renamed ContentKeyType.Aes128Bit.

  • The usage pattern for AsyncCaptureImage was updated to the standard .NET event based asynchronous pattern. In Silverlight 4, you call CaptureImageAsync, and handle CaptureImageCompleted. The desired image is the Result value of event data, and is a WriteableBitmap as before.

    // Old usage
void CallbackFunc(WriteableBitmap img) { //... }
myCaptureSource.AsyncCaptureImage(CallbackFunc);
// New usage.
void CallbackFunc(object sender, CaptureImageCompletedEventArgs args) {//...}
myCaptureSource.ImageCaptureCompleted += CallbackFunc;
myCaptureSource.ImageCaptureAsync();

COM interop API changes

The types used for COM interop in Silverlight 4 have moved to a different namespace, and the type names changed. 

namespace System.Windows.Interop
{
    public sealed class ComAutomationEvent
    public sealed class ComAutomationEventArgs : EventArgs
    public delegate void ComAutomationEventHandler(object sender, ComAutomationEventArgs e)
    public static class ComAutomationFactory
}

Changed to:

namespace System.Runtime.InteropServices.Automation
{
    public sealed class AutomationEvent
    public sealed class AutomationEventArgs : EventArgs
    public static class AutomationFactory
}

RichTextBox.TextWrapping default value set to Wrap

The default value of TextWrapping is TextWrapping.Wrap for Silverlight 4. It previously defaulted to TextWrapping.NoWrap.

Behavior change when setting Binding in XAML and target is a DependencyObject

In Silverlight 4, bindings set in XAML on a dependency property of a DependencyObject will attach a BindingExpression to the properties instead of setting Binding objects.  In Silverlight 3, target of a binding had to be a FrameworkElement, so this case did not come up. Binding to any DependencyObject dependency property was added in Silverlight 4 Beta.

You are NOT affected by this change if any of the following apply:

  • Your application is compiled or targeted for Silverlight 3

  • Your target object is a FrameworkElement (most objects used in UI-related bindings are a FrameworkElement derived class)

  • The target property is a CLR property instead of a dependency property

Before the change:

<local:MyDependencyObject MyProperty="{Binding MyItem}" />

This sets MyProperty to a Binding object with path MyItem.

After the change:

<local:MyDependencyObject MyProperty="{Binding MyItem}" />

This attaches a BindingExpression to the MyProperty that listens to the path MyItem (like calling SetBinding). Silverlight 4 applications that want the behavior of a Binding object being set should make the target property a CLR property instead of a DependencyProperty. This is consistent with the FrameworkElement behavior.

HtmlBrush has been renamed to WebBrowserBrush

Change all references to HtmlBrush to WebBrowserBrush. CLR namespace and assembly location remains identical.

ListBoxItem visual states have been renamed

ListBoxItem has renamed two of its named visual states.

  • The Loaded visual state from Silverlight 4 Beta is named AfterLoaded in Silverlight 4

  • The Unloaded visual state from Silverlight 4 Beta is named BeforeUnloaded in Silverlight 4

This change affects you if you have written templates for items controls that include these visual states. You should change templates to use the Silverlight 4 state names. This change might also affect you if you have written VisualStateManager logic that consumes state names as defined by ItemsControl.

The state names are reflected in the CLR attribution on the ListBoxItem type. The relevant states did not exist in the Silverlight 3 ListBoxItem.

Bindings in a Style Setter are not supported

In Silverlight 4 Beta, bindings in a style setter (the Setter.Property value) were permitted by syntax (although they did not function as expected when compared to WPF equivalent usages).

In Silverlight 4, bindings in a style setter are blocked at the syntax level. This was also the case in Silverlight 3.

NoteNote:

Binding in a style setter is permitted in Silverlight 5.

CultureNotFoundException API Changes

The following API existed in CultureNotFoundException in Silverlight 4 Beta, but is removed for Silverlight 4.

        public CultureNotFoundException(string message, int invalidCultureId, Exception innerException);
        public CultureNotFoundException(string paramName, int invalidCultureId, string message);
        public virtual Nullable`1<int> InvalidCultureId { get; }

Contract.ContractFailed API Changes

System.Diagnostics.Contracts.Contract.ContractFailed existed in Silverlight 4 Beta, but is removed for Silverlight 4. ContractFailedEventArgs is also removed.

Action and Func (T5+) API Changes

The .NET Framework includes several varieties of Action and Func delegates. This breaking change specifically impacts the Silverlight Action and Func delegates that have at least 5 input parameters (parameter name of T5 exists), which are also those that are new to .NET Framework 4. All such delegates were in the assembly System.Core both in Silverlight 4 Beta and Silverlight 4 RC. These are moved to mscorlib as of Silverlight 4. If you have used these delegates in Beta/RC, you must recompile using Silverlight 4 RTM bits.