Silverlight 确保您的 Silverlight 应用程序能与 Silverlight 4 一起工作

Silverlight 确保您的 Silverlight 应用程序能与 Silverlight 4 一起工作 在 Silverlight 3 和 Silverlight 4 之间，针对 Silverlight 运行时和 Silverlight 工具做出了一些更改。对于这些更改，以下原则适用：     *       无需任何更改，多数 Silverlight 3 应用程序都可与 Silverlight 4 一起使用。     *       要求重大更改时，Silverlight 将通过使用“突发模式”尽量同时保持对旧行为和新行为的支持。 即便如此，对 Silverlight 组件所做的某些更改仍可能导致旧的基于 Silverlight 的应用程序失败（在编译时、XAML 加载时或可能在设计时）或操作异常。 本主题介绍在 Silverlight 3 和 Silverlight 4 之间所做的更改。本主题不介绍 Silverlight 4 的新功能或增强功能。有关 Silverlight 4 中的新增功能的信息，请参见 Silverlight 4 中的新增功能。 注意说明： 有关对本主题的更正和增补，请参见 Silverlight SDK blog（Silverlight SDK 博客）。 本主题包含以下各节：     *       XAML 分析器更改 本节介绍 Silverlight 4 中的 XAML 分析器更改。     *       自 Silverlight 3 以来的重大更改 本节中介绍的更改可能会破坏用户在 Silverlight 4 运行时上运行的为 Silverlight 3 编写的应用程序，即便应用程序清单的目标为 Silverlight 3 也是如此。     *       突发模式行为 本节介绍运行时或其 API 中的哪些部分包括特定于版本的行为差异。这些行为差异基于应用程序的目标运行时版本。这些更改往往代表针对 Silverlight 4 的@L_616_13@修复，但 Silverlight 3 行为作为特定的突发模式仍然可以访问，仅在应用程序的目标是 Silverlight 3 运行时的情况下才可以使用突发模式。在应用程序的逻辑依赖于 Silverlight 3 行为时才这样做。     *       升级重大更改 本节介绍在您重新编译 Silverlight 3 应用程序并准备面向 Silverlight 4 时涉及的相关更改。     *       自 Silverlight 4 Beta 以来的重大更改 本节介绍专门为 Silverlight 4 Beta（Silverlight 运行时的最新公开发布版本）编译的应用程序才会涉及的相关更改。没有可用于 Silverlight 4 Beta 运行时行为的突发模式。 XAML 分析器更改 Silverlight 4 引入了更新的 XAML 分析器。同时为保持兼容性，Silverlight 4 运行时还保留了原始 Silverlight 3 XAML 分析器，并用它来分析面向 Silverlight 3 的任何应用程序的 XAML。这意味着如果您继续以 Silverlight 3 为目标，对 Silverlight 3 有效的任何原始 XAML 行为仍将有效，只要该 XAML 行为与“升级重大更改”一节中所列的特定重大更改没有冲突。其实际效果与用于 XAML 加载的突发模式相似。 如果将以前面向 Silverlight 3 的 Silverlight 项目升级为现在面向 Silverlight 4，则可能需要更改您的 XAML。如果要升级 Silverlight 4 Beta 项目，则可能需要更改您的 XAML。Silverlight 4 Beta XAML 分析器行为与 Silverlight 3 XAML 分析器行为大体相同。 影响您应用程序的 XAML 的 XAML 行为差异涉及面太广，无法在此一一列出，改为在其他主题中介绍。有关更多信息，请参见 Silverlight 3 和 Silverlight 4 之间的 XAML 处理差异或 Silverlight 版本和 WPF 之间的 XAML 处理差异。 自 Silverlight 3 以来的重大更改 本节介绍的更改可能会破坏 Silverlight 3 应用程序。其中许多更改实际上是@L_616_13@修复。 不过，如果您的 Silverlight 3 应用程序已经针对这些@L_616_13@添加了解决方法，您可能不得不取消这些解决方法，这样在 Silverlight 4 运行时上运行时，您的应用程序才能正常工作。 当应用程序属性与新的 Silverlight 4 属性冲突时，出现 XAML 分析 AmbiguousmatchException 如果您在 XAML 中设置属性且两个不同的属性具有相同的简单名称，Silverlight XAML 分析器（特别是处理兼容性的并行 XAML 分析器）将引发 AmbiguousmatchException。如果一个属性名称匹配候选者是基类的成员，另一个候选者是派生类的成员，就可能引发异常。在根据 Silverlight 3 内核生成应用程序时，可能只存在应用程序定义的属性。但是，如果高版本的 Silverlight（如 Silverlight 4）添加具有相同简单名称的属性且该属性在通过新基类定义继承的内核运行时成员定义中存在，则该属性名称现在对于 XAML 分析器有歧义。 例如，Silverlight 3 应用程序可能从 TextBox 派生并针对自定义类声明名为 Watermark 的 XAML 可访问的新属性。在 Silverlight 3 中，TextBox 不具有名为 Watermark 的属性，因此在 Silverlight 3 中应用程序进行 XAML 分析时不会出现名称歧义。但是，TextBox 的 Silverlight 4 内核库定义引入了名为 Watermark 的属性，因此在根据 Silverlight 4 内核运行时执行时，简单属性名称的 Silverlight 3 XAML 查找进程现在有歧义。 此问题只影响 XAML 使用；在这种情况下使用代码中的属性没有歧义。仅当两个属性定义类型之间存在子类/超类关系时，才存在此问题。例如，MyButton.Watermark 属性不会有问题，因为 MyButton 不是 TextBox 的子类。 此问题只影响基于 Silverlight 2 和 Silverlight 3 生成的应用程序。Silverlight 4 应用程序使用新的 XAML 分析器，该分析器可以解决此类名称歧义的问题。真正的 Silverlight 3 运行时中存在同样的 XAML 分析器问题。如果 Silverlight 2 应用程序定义并使用在 Silverlight 3 中添加的属性名称，将出现 AmbiguousmatchException。 以下章节列出在 Silverlight 4 中添加到通用基类（DependencyObject、UIElement、FrameworkElement、Control 和 System.Windows.dll 中的 Control 子类）的属性。每个属性表示是子类中名称歧义候选者的属性名称。     *       FrameworkElement.FlowDirection     *       FrameworkElement.Unloaded     *       拖放 API（AllowDrop、DragEnter、DragLeave、DragOver、Drop）     *       操作 API（ManipulationCompleted、ManipulationDelta、ManipulationStarted）     *       UIElement.MouseRightButtonDown,UIElement.MouseRightButtonUp     *       IME API（TexTinput、TexTinputStart、TexTinputUpdate）     *       其他文本控件 API（几个与文本相关的类型的 BaselineOffset、TextBox.InputScope、TextBox.Watermark、ButtonBase.Command、ButtonBase.CommandParameter）     *       SELEctor.SELEctedValue,SELEctor.SELEctedValuePath 遇到此问题的应用程序必须使用 Silverlight 4 重新编译和生成目标文件；重新编译后的应用程序使用新的 XAML 分析器，可以正确解析。 切换全屏模式现在将重新运行命中测试 切换全屏模式现在将重新运行命中测试。这样做是为了允许在切换之前处于鼠标之下的控件更新其 MouSEOver 状态。 在切换全屏模式时，鼠标指针很可能因 Silverlight 插件大小的更改“跳转”到其他位置。在退出全屏模式时，鼠标指针可能位于插件之外。在以往，不会发出鼠标消息以通知控件鼠标指针不再位于这些控件上方。现在，在切换全屏模式后完成布局时，将引发鼠标事件以重新运行命中测试，并允许控件按需更改状态。 有关更多信息，请参见全屏支持。 更改 ItemControl 的 DisplaymemberPath 和 ItemTemplate 属性现在将重新创建所有容器 在 Silverlight 3 中，设置项模板的 ItemTemplate 和 DisplaymemberPath 属性（如在下面的代码中）在完成 ListBox 测量后没有任何效果。 XAML 复制 <ListBox x:Name="lb" ItemTemplate="{Staticresource lbItem}"> VB C# C++ F# JScript 复制 lb.ItemTemplate = lbItemTemplate; lb.DisplaymemberPath = itemDisplayPath; 在 Silverlight 4 中，此代码将使所有已实现的容器无效，并重新创建它们，即便是在测量完容器后。 共享的 BitmapImage 源 当两个 BitmapImage 控件共享同一 BitmapImage 源，并且二者均未显式设置 Width/Height（均使用自然大小），第二个 Image 不在 Silverlight 3 中呈现其 BitmapImage。此行为在 Silverlight 4 中已纠正，现在两个 Image 控件均应正确呈现其内容。 IronPython 2.0.2 和更早版本 Silverlight 4 不能与 IronPython 的早期版本一同工作，请升级为 IronPython 2.0.3 或更高版本，这些版本可通过 http://ironpython.codeplex.com/ 来下载。 Microsoft.Jscript.Compiler.dll / Microsoft.Jscript.Runtime.dll Silverlight 4 不能与 Microsoft.Jscript.Compiler.dll / Microsoft.Jscript.Runtime.dll（亦称“DLR Jscript”，有时也称为“托管 Jscript”）一同工作。最近发布的试用 DLR Jscript 是作为 Dynamic Languages SDK 0.4.0 Alpha 的一部分发布的。此功能因不能完全发挥作用已被取消，不再使用。有关详细信息，请参见 http://dlr.codeplex.com/Thread/View.aspx?ThreadId=58121。（不应将 DLR Jscript 与更常用的基于浏览器的 Silverlight 的 JavaScript API 相混淆，后者一直有效） DRM 和操作系统位于 FAT32 分区的客户端 在 Silverlight 3 中，DRM 可以在操作系统安装在 FAT32 驱动器或分区的客户端系统上正常工作。（对于特意不使用安装或操作系统转换默认设置的少量 Windows XP 操作系统存在这种情况。） 在 Silverlight 4 中，DRM 功能在操作系统安装在 FAT32 驱动器或分区的客户端系统上不能正常工作。 建议的用户解决方法是转换到 NTFS。请参见 http://support.microsoft.com/kb/314097/。 突发模式更改 Silverlight 团队曾想要在 Silverlight 4 中修复若干 Silverlight 3 @L_616_13@。但在修复其中一些@L_616_13@后，某些现有的 Silverlight 3 应用程序可能会被破坏。为了避免此问题，Silverlight 团队通过为运行时行为创建“突发模式”来解决这些可能产生问题的更改。突发模式更改是这样一种更改：如果 Silverlight 4 运行时检测到应用程序面向 Silverlight 3，该运行时将使其行为产生分支。这样，Silverlight 4 将成为“@L_616_13@兼容的”运行时。但是，如果您面向 Silverlight 4 重新编译应用程序，则可能需要重新检查所指出的突发模式行为。 如果您的应用程序的 RuntimeVersion 指定 Silverlight 3，则运行时将在突发模式下运行。处于突发模式下时，运行时回退到与突发模式更改关联的 Silverlight 3 行为，并在这些情况下始终这样操作，就像该运行时实际上是未升级的 Silverlight 3 运行时一样。 Silverlight 4 运行时通过使用 RuntimeVersion 检测应用程序是否是为 Silverlight 3 设计的。RuntimeVersion 设置为 XAP 文件的 AppManifest.xaml 中的属性： 复制 <Deployment xmlns="http://scheR_543_11845@as.microsoft.com/client/2007/deployment"             xmlns:x="http://scheR_543_11845@as.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 反映在编译应用程序时位于开发人员计算机上的 Silverlight 的内部版本号。 如果使用 Silverlight 4 工具编译您的应用程序并且将目标专门设定为 Silverlight 3，您就潜在地调用了突发模式，就像是使用 Silverlight 3 工具编译了应用程序一样。 范围和容器中的正确空白处理 Silverlight 3 中的 TextBlock（以及 Silverlight 4 Beta 中的 RichTextArea）��� <Span> 或 <Run> 部分中存在@L_616_13@，此时 XAML 中的空白（通常用于格式设置）实际上用作内容。这有时会要求限制在 XAML 源中使用换行符，导致 XAML 的可读性较差。此行为对于 Silverlight 3 是突发的，作为 Silverlight 3 和 Silverlight 4 之间的 XAML 处理差异中所述更大 XAML 分析器行为的一部分。 Silverlight 4 中的文本容器接受文本内容，并在对象模型中为任何“innertext”文本内容创建隐式文本运行。这样才能在由 CRLF 分隔的文本元素之间生成空白。例如： 复制 <Run>Some</Run> <Run>Text</Run> 转换为： 复制 <Run>Some</Run><Run> </Run><Run>Text</Run> Silverlight 4 中放宽了裁剪前导和尾随空白的条件。以往的行为会裁剪隐式 Run 元素的前导空白，除非 Run 的前面有一个显式 Run。Silverlight 4 行为会裁剪前导空白，除非隐式 Run 的前面有一个并非 Run 的显式文本元素（例如：Span、InlineUIContainer、Hyperlink）或有一个显式 Run。 面板的 Clear 方法现在调用 InvalidateMeasure 在 Silverlight 4 中，当调用 Panel 项集合的 Clear 方法时，现在会引发针对 InvalidateMeasure 的调用。这将在下一个计时周期开始时触发布局。在 Silverlight 3 中，调用 Clear 仍将对 Panel 布局没有任何影响。 VirtualizingStackPanel.MouseWheelUp 和 VirtualizingStackPanel.MouseWheelDown 现在滚动三行 在 Silverlight 3 已编译应用程序中，MouseWheelUp 和 MouseWheelDown 方法仍将滚动一行。但是在 Silverlight 4 应用程序中，这些方法将滚动三行。 ImageBrush.Imagesource 现在返回 Imagesource 对象而不是 Urisource 在 Silverlight 3 应用程序中，ImageBrush.Imagesource 返回其 Imagesource 的 Urisource（字符串）。这与 Silverlight 1.0 中的最初 JavaScript 行为是相同的。 在 Silverlight 4 中，将返回实际 Imagesource 对象，该对象可以是 WriteableBitmap 或 BitmapImage。 在动画期间更改基值现在可发挥预期作用 在 Silverlight 3 中，如果在某个活动的动画中间对某个属性调用了 SETVALue，结果仅适用于该计时周期。SETVALue 将正确地更改该值，但是在活动动画的下一计时周期，该动画将覆盖设置的值。这种情况看上去常常就像什么都没有发生（对新值的更改太快，使用户难以觉察）。SETVALue 调用并不更改动画的基值（GetAnimationBaseValue 的结果）。停止动画时，基值将返回给在开始动画之前属性所具有的值，忽略 SETVALue。 在 Silverlight 4 中，如果在活动动画的中间发生属性值更改，SETVALue 调用将修改动画的基值。停止动画时，该动画将使用新的基值。这与 WPF 中的行为相同。（请注意，HoldEnd 动画不一定受此更改影响）。 当动画有效时 ReadLocalValue 返回本地值 在 Silverlight 3 中，对属性进行动画处理并且动画正在运行时，针对 ReadLocalValue 的调用将返回经过动画处理的值。 在 Silverlight 4 中，针对 ReadLocalValue 的调用将返回本地值。这与 WPF 中的行为相同。如果需要经过动画处理的值，请调用 GetValue。 在样式中的重复 setter 全部引用同一附加属性时，不会调用这些 setter 在 Silverlight 3 中，可以使用多个 Style Setter 对同一附加属性设置两次。特定的方案会用到此特性。 在 Silverlight 4 中，不再支持此行为。在 Setters 中两次设置同一附加属性并不属于语法@L_616_13@。但是，只有最后一个引用附加属性的 Setter 才会被 Silverlight 样式子系统实际调用，任何其他 setter 的结果都是无操作 (no-op)。此行为与 WPF 行为相同。 浏览器缩放和 Content.Resized 在 Silverlight 4 中，如果应用程序与 Resized 事件挂钩，Silverlight 内容区域的视图将在浏览器缩放级别更改时自动缩放。如果 Silverlight 4 应用程序要禁用自动浏览器缩放，该应用程序必须将 EnableAutoZoom 属性显式设置为 false。 Silverlight 3 认定侦听 Resized 的应用程序自己会处理浏览器缩放，所以禁用自动浏览器缩放。因此，如果应用程序面向 Silverlight 3，则突发模式行为是：没有任何缩放行为与 Resized 关联。 MEF API 更改 以下是对 Silverlight MEF 组件（System.ComponentModel.Composition 程序集和相关组件）中存在的托管扩展框架 (MEF) API 的特定更改：     *       PartCreator<T> 已@L_944_154@为 ExportFactory<T>，移到 System.ComponentModel.Composition.Initialization.dll     *       ParTinitializer 已@L_944_154@为CompositionInitializer     *       CompositionHost.InitializeContainer 已@L_944_154@为CompositionHost.Initialize     *       PackageCatalog 已替换为DeploymentCatalog 字符串比较和 CultureInfo String 和 Char 类的某些字符串比较 API 对于如何获取有效 CultureInfo 使用不同的逻辑，具体取决于应用程序在 Silverlight 3 还是 Silverlight 4 上运行。这仅适用于重载未传递特定 CultureInfo 的情况。该行为是突发的，因此 Silverlight 3 应用程序不必纠正它。下表列出了 API 差异： 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 从 IList、IList<T> 填充 ItemsControl 在 Silverlight 3 中，如果使用 IList 或 IList<T> 填充 ItemsControl，系统使用枚举器执行填充。在 Silverlight 4 中，系统使用专用索引器（和 Count）执行填充。 升级重大更改 如果将项目升级为面向 Silverlight 4 运行时，则往往需要先解决此类别中所列的问题，然后才能重新编译您的应用程序。您可能还需要重新检查您的应用程序逻辑，该逻辑可能一直依赖突发模式行为。 有关更多信息，请参见上文中的“突发模式更改”一节。 项目更改 如果将以前面向 Silverlight 3 的 Silverlight 项目升级为专门面向 Silverlight 4，则可能需要对项目结构进行某些更改。还可能需要对该项目所用的文件和资源进行更改。在某些情况下，这是因为某些行为允许作为 Silverlight 3 突发行为，但在改为面向 Silverlight 4 后不再允许这样做。 一些类型已从 Silverlight SDK 移至核心运行时 以下类型已从 Silverlight SDK 移至核心运行时：     *       System.ComponentModel.IEditableCollectionView     *       System.ComponentModel.NewItemPlaceholderPosition     *       System.Windows.Data.CollectionViewGroup     *       System.Windows.Data.PropertyGroupDescription 旧程序集：System.Windows.Data.dll 新程序集：System.Windows.dll 现有的 Silverlight 3 应用程序应该能照常工作，因为 System.Windows.Data.dll 客户端程序集通常在 XAP 文件中分发。 如果使用 Silverlight 4 工具编译您的应用程序，使其面向 Silverlight 4，该应用程序将使用核心运行时库中的类。 而且，在 Silverlight 4 Beta 和 Silverlight 4 之间，System.Windows.Navigation 命名空间中的某些（不是全部）API 已从 System.Windows.Controls.Navigation.dll 移到内核 System.Windows.dll。现在位于 System.Windows 中的 API 有：NavigatedEventHandler、NavigaTingCancelEventArgs、NavigaTingCancelEventHandler、NavigationEventArgs、NavigationMode。 修复了 TabControl 键盘导航 Silverlight 3 在 TabControl 的键盘导航模式中，按上箭头键激活的是下一个 TabItem，按下箭头键激活的是上一个 TabItem。这在 TabStripPlacement 设置为 Left 或 Right 时将导致与直观行为相悖的行为。在这种情况下，按上箭头键激活的是当前活动的 TabItem 之下的 TabItem，按下箭头键激活的是当前活动的 TabItem 之上的 TabItem。此行为仍存在于 Silverlight 3 应用程序中；TabControl 位于 System.Windows.Controls.dll 程序集中，该程序集是一个客户端库，经常打包到 XAP 文件中。 Silverlight 4 在 Silverlight 4 中按上箭头键激活的是上一个 TabItem（即：当 TabStripPlacement 设置为 Left 或 Right 时，垂直布局模式中的当前活动 TabItem 之上的项）。按下箭头键激活的是下一个 TabItem（垂直布局模式中的当前活动 TabItem 之下的项）。如果引用或分发 Silverlight 4 System.Windows.Controls.dll 程序集，则这是更新的行为。 控件现在具有内置的鼠标滚轮支持 在 Silverlight 4 中，以下控件现在具有内置的 MouseWheel 事件支持：     *       ListBox     *       TEXTBox     *       ComboBox     *       ScrollViewer     *       Calendar     *       DatePicker     *       DataGrid 在 Silverlight 3 中，没有内置的 MouseWheel 支持。 如果将应用程序从 Silverlight 3 升级到 Silverlight 4，您可能要删除以前所有的应用程序级别的特定鼠标滚轮事件处理，有可能需要在 HTML DOM 中删除。这可能适用于以下任意控件：ListBox、TextBox、ComboBox 和 ScrollViewer。有关更多信息，请参见鼠标轮输入。 注意说明： 还有一些具有 MouseWheel 支持的控件未在此处列出，因为它们不存在于 Silverlight 3 中。一个示例是 RichTextBox。检查各个控件引用页，看是否存在有关 MouseWheel 处理的 OnMouseWheel 重写或其他备注。 DataGrid 中的货币更改时的 DataGridCell 对象和自动化焦点 当 DataGrid 中的货币更改时，Silverlight 4 中的 DataGridCell 对象接收自动化焦点，焦点不再保留在 DataGrid 本身上。 一些详细信息：UI 自动化客户端原先不获取有关当前具有焦点的单元格的信息，因为 DataGridCell 对象不是可获得焦点的控件（尝试的 Focus 返回 false）。这一点没有变化。DataGridCell 对象在 UI 中仍不可获得焦点。但是，对于 Silverlight 4，这些对象将在 DataGrid 货币更改时接收“自动化焦点”。现在当您按 Tab 键进入 DataGrid 并使用箭头键更改货币时，自动化焦点将移至各个单元格同级，以便 UI 自动化客户端能够接收这些单元格的特定自动化属性信息。以前，自动化焦点保留在 DataGrid 上；它基于 Silverlight 3 System.Windows.Controls.Data.dll 作为 Silverlight 3 行为保留。 System.serviceModel.PollingDuplex.dll 程序集已重构 如果此前引用过 System.serviceModel.PollingDuplex.dll 程序集，在将项目升级到 Silverlight 4 之后，您必须手动添加对 System.serviceModel.Extensions.dll 扩展程序集的引用。最初的程序集已被重构，有些类已移至新程序集。 自 Silverlight 4 Beta 以来的重大更改 如果您创建了 Silverlight 4 Beta 应用程序，Silverlight 4 Beta 与 Silverlight 4 之间存在一些重大更改，下面各节将对此进行介绍。 RichTextArea 已重���名为 RichTextBox RichTextArea 已@L_944_154@为 RichTextBox。CLR 命名空间和程序集位置保持不变。 针对 DRM API 的更改 自 Silverlight 4 Beta 以来更改了一些与 DRM 相关的 API。 以前 复制 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 datetiR_543_11845@e ExpirationDate; } public enum ContentKeyType {   AES128Bit,  Cocktail } 之后 复制 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<datetiR_543_11845@eOffset> ExpirationDate; } public enum ContentKeyType {   Aes128Bit,  Cocktail } TextSELEction.SetPropertyValue 已@L_944_154@为 TextSELEction.ApplyPropertyValue 如果您的代码关联到 RichTextArea/RichTextBox（使用 TextSELEction.SetPropertyValue 设置选定文本的格式），您必须将此代码改为调用 TextSELEction.ApplyPropertyValue。 INotifyDataErrorInfo 和 DataErrorsChangedEventArgs 移至 System.Windows.dll Silverlight 4 Beta 中添加了 INotifyDataErrorInfo 和 DataErrorsChangedEventArgs。这些类型在 Silverlight 4 中已从 System.dll 移至 System.Windows.dll。如果您使用这些类型，则必须重新编译您的项目，并且可能需要调整您的引用程序集。 WebBrowser.ScriptNotify 签名更改 复制 public event NotifyEventHandler ScriptNotify; 更改为： 复制 public event EventHandler<NotifyEventArgs> ScriptNotify; 而且，WebBrowser.LoadCompleted 现在使用更具体的委托：LoadCompletedEventHandler。您可以继续使用 EventHandler，您的应用程序仍将编译，但是应用程序可能要升级以接收 NavigationEventArgs 事件数据。 NotificationWindow API 更改 在 NotificationWindow API 中： 复制 public bool Visible { get; } public event EventHandler<EventArgs> Closed; 更改为： 复制 public Visibility Visibility { get; } public event EventHandler Closed; 网络摄像机和输出保护 API 的更改 存在一些与网络摄像机和输出保护相关的 API 更改。     *       针对音频/视频捕获设备的集合以及支持的格式现在返回 ReadOnlyCollection<T> 格式的不可变的集合。这将影响对 GetAvailableAudioCaptureDevices、GetAvailableVideoCaptureDevices 或 VideoCaptureDevice 方法的所有调用。     *       Connectors @L_944_154@为 VideoOutputConnectors 且返回的集合不可变：ReadOnlyCollection<VideoOutputConnector>。     *       若干枚举的大小写已更改：       复制       VGA -> Vga       DVI -> Dvi       HDMI -> Hdmi       LVDS -> Lvds       SDI -> Sdi       UDIExternal -> UdiExternal       UDIInternal -> UdiInternal     *       CanEnablehdcp @L_944_154@为 CanEnablehdcp，CanEnableCGMSA @L_944_154@为 CanEnableCgmsa。     *       VideoFormat.Height @L_944_154@为 VideoFormat.PixelHeight。VideoFormat.Width @L_944_154@为 VideoFormat.PixelWidth。     *       WaveFormatType.PCM @L_944_154@为 WaveFormatType.Pcm。     *       ContentKeyType.AES128Bit @L_944_154@为 ContentKeyType.Aes128Bit。     *       AsyncCaptureImage 的使用模式已更新为基于标准 .NET 事件的异步模式。在 Silverlight 4 中，您调用 CaptureImageAsync 并且处理 CaptureImageCompleted。所需的图像是事件数据的 Result 值，且和以前一样是一个 WriteableBitmap。       复制       // Old usage       void CallBACkFunc(WriteableBitmap img) { //... }       myCapturesource.AsyncCaptureImage(CallBACkFunc);       // New usage.       void CallBACkFunc(object sender,CaptureImageCompletedEventArgs args) {//...}       myCapturesource.ImageCaptureCompleted += CallBACkFunc;       myCapturesource.ImageCaptureAsync(); COM 互操作 API 更改 用于 Silverlight 4 中的 COM 互操作的类型已移至新的命名空间，并且类型名称已更改。 复制 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 } 更改为： 复制 namespace System.Runtime.Interopservices.Automation {     public sealed class AutomationEvent     public sealed class AutomationEventArgs : EventArgs     public static class AutomationFactory } RichTextBox.textwrapping 默认值现已设置为 Wrap 对于 Silverlight 4，textwrapping 的默认值为 textwrapping.Wrap。以前的默认值为 textwrapping.Nowrap。 在 XAML 中设置 Binding 且目标为 DependencyObject 时的行为更改 在 Silverlight 4 中，在 XAML 中对 DependencyObject 的依赖项属性设置的绑定将向这些属性附加一个 BindingExpression 而不是设置 Binding 对象。  在 Silverlight 3 中，绑定目标必须是一个 FrameworkElement，所以不会出现上述情况。在 Silverlight 4 Beta 中添加了对任何 DependencyObject 依赖项属性的绑定。 如果存在以下任何情况，则您不会受到此更改的影响：     *       应用程序面向 Silverlight 3 编译或以此为目标。     *       目标对象是一个 FrameworkElement（在与 UI 相关的绑定中使用的多数对象都是 FrameworkElement 派生类）     *       目标属性是 CLR 属性而不是依赖项属性 在这一更改前： 复制 <local:MyDependencyObject MyProperty="{Binding MyItem}" /> 这将 MyProperty 设置为具有路径 MyItem 的 Binding 对象。 在这一更改后： 复制 <local:MyDependencyObject MyProperty="{Binding MyItem}" /> 这会将 BindingExpression 附加到侦听路径 MyItem 的 MyProperty（类似调用 SetBinding）。想要设置 Binding 对象的行为的 Silverlight 4 应用程序应将目标属性设置为 CLR 属性而不是 DependencyProperty。这与 FrameworkElement 行为是一致的。 HtmlBrush 已@L_944_154@为 WebBrowserBrush 将针对 HtmlBrush 的所有引用更改为 WebBrowserBrush。CLR 命名空间和程序集位置保持不变。 ListBoxItem 可视状态已@L_944_154@ ListBoxItem 已对它的两个指定可视状态进行@L_944_154@。     *       Silverlight 4 Beta 中的 Loaded 可视状态现在名为 AfterLoaded     *       Silverlight 4 Beta 中的 Unloaded 可视状态现在名为 BeforeUnloaded 如果您已经为包括这些可视状态的项控件编写模板，则此更改对您有影响。应该更改这些模板，以使用新的状态名称。如果您编写的 VisualStateManager 逻辑使用 ItemsControl 中定义的状态名称，则此更改也可能对您有影响。 新状态名称反映在针对 ListBoxItem 类型的 CLR 特性中。相关状态在 Silverlight 3 ListBoxItem 中不存在。 不支持样式 Setter 中的绑定 在 Silverlight 4 Beta 中，样式 setter 中的绑定（Setter.Property 值）在语法上是允许的（尽管与等效的 WPF 用法相比，这些绑定不能发挥预期作用）。 在 Silverlight 4 中，样式 setter 中的绑定现已在语法级别上禁用。在 Silverlight 3 中也同样禁用。 CultureNotFoundException API 更改 以下 API 存在于 Silverlight 4 Beta 的 CultureNotFoundException 中，但是已从 Silverlight 4 中删除： 复制         public CultureNotFoundException(String message,int invalidCulturEID,Exception innerException);         public CultureNotFoundException(String paramname,String messagE);         public virtual Nullable`1<int> InvalidCulturEID { get; } Contract.ContractFailed API 更改 System.Diagnostics.Contracts.Contract.ContractFailed 存在于 Silverlight 4 Beta 中，但是已从 Silverlight 4 中删除。还删除了 ContractFailedEventArgs。 Action 和 Func (T5+) API 更改 .NET Framework 包含几个 Action 和 Func 委托的元数。这个重大更改专门影响具有至少 5 个输入参数（T5 的参数名称存在）的 Silverlight Action 和 Func 委托，这些委托对于 .NET Framework 4 也是新的。所有这些委托在 Silverlight 4 Beta 和 4 RC 中以前都位于程序集 System.Core 中。现在它们已移到 mscorlib 中。如果在 Beta/RC 中使用了这些委托，必须使用 Silverlight 4 RTM 位重新编译。 请参见 任务 如何创建新 Silverlight 项目 概念 Silverlight 的 JavaScript API XAML 概述 其他资源 Silverlight 4 中的新增功能