Forward and Backward Compatibility

An application built with WPF 3.0 will run on the WPF 3.5 runtime.

An application built with WPF 3.5 will execute on the 3.0 runtime if the application only uses features that are available in WPF 3.0.

WPF 3.5 defines a new XML namespace, http://schemas.microsoft.com/netfx/2007/xaml/presentation. When building an application using WPF 3.5, you can use this namespace or the namespace defined in WPF 3.0.

Cookies can be shared between XBAPs and Web applications from the same site of origin.

Improved XAML IntelliSense experience for higher productivity.

Expanded localization support.

Visual and Nonvisual Add-Ins in WPF

An extensible application exposes functionality in a way that allows other applications to integrate with and extend its functionality. Add-ins are one common way for applications to expose their extensibility. In the .NET Framework, an add-in is typically an assembly that is packaged as a dynamic link library (.dll). The add-in is dynamically loaded by a host application at run time to use and extend services exposed by the host. The host and the add-in interact with each other through a well-known contract, which typically is a common interface that is published by the host application.

Once an application supports add-ins, first-party and third-party developers can create add-ins for it. There are many examples of these types of applications, including Office, Visual Studio, and Microsoft Windows Media Player. For example, the add-in support for Microsoft Windows Media Player allows third parties to create DVD decoders and MP3 encoders.

The .NET Framework implements the building blocks for allowing applications to support add-ins. However, the time and complexity that is required to build that support can be expensive, considering that a robust add-in design needs to handle the following:

Versioning: Ensuring that host applications and add-ins can still communicate when new versions of either are created.

Rather than requiring you to solve these problems, .NET Framework now includes a set of types, located in the System.AddIn namespace, that are collectively known as the "add-in model". The .NET Framework add-in model provides functionality for each of the common add-in behaviors listed above.

In some scenarios, though, it may also be desirable to allow add-ins to integrate with and extend host application UIs. WPF extends the .NET Framework add-in model to enable this support, which is built around displaying a FrameworkElement owned by an add-in in the UIs of a host application. This enables WPF developers to create applications to support the following common scenarios:

Firefox Support for XBAPs

A plug-in for WPF 3.5 enables XBAPs to be run from Firefox 2.0, a feature that is not available from WPF 3.0. Key features include the following:

If Firefox 2.0 is your default browser, XBAPs honor the configuration. That is, Internet Explorer is not used for XBAPs if Firefox 2.0 is the default.

The same security features available to XBAPs running Internet Explorer are available to XBAPs running in Firefox 2.0, including partial-trust security sandboxing. Additional browser-provided security features are browser-specific.

Cookies

Standalone WPF applications and XBAPs can create, obtain, and delete both session and persistent cookies. In WPF 3.5, persistent cookies can be shared between XBAPs, Web servers, and HTML files that have the same site of origin.

You now have the ability to cache images that are downloaded over HTTP to the local Microsoft Internet Explorer temporary file cache, so that subsequent requests for the image come from local disk, rather than the Internet. Depending on the sizes of your images, this can be a significant network performance improvement. The following members have been added to support this feature:

The data model enables validation on the business layer by providing support for the IDataErrorInfo interface. In addition, the validation model now supports using property syntax to set validation rules.

Support for IDataErrorInfo

The data validation model now supports the IDataErrorInfo interface to enable a business object to determine the validity of the input. The interface defines an indexer that takes a property name and returns a string. The validation rule DataErrorValidationRule, which checks for exceptions returned by the indexer, has been added. For an example, see Business Layer Validation Sample.

The annotations framework now exposes the capabilities for matching annotations with the corresponding annotated objects. A new interface, IAnchorInfo, has been added. In addition, a new method, GetAnchorInfo, which returns an IAnchorInfo object, has been added to the AnnotationHelper class.