What's New in Sync Framework 2.0

Sync Framework 2.0 includes new and enhanced features in the following areas:

• Database providers

  • New providers for SQL Server and SQL Server Compact

  • Robust memory-based batching

  • Provisioning and management APIs

  • Snapshot initialization

  • Flexibility regarding topology shape

  • Performance improvements

• File synchronization provider

  • Data conversion

• Custom Providers

  • Simple providers

  • Data conversion between providers

  • Filtering

  • Conflict handling

  • Tracing

  • Change application service

  • Metadata storage service serializer

  • Provider converters

  • Knowledge improvements

  • Compatibility levels

  • Obsolete interfaces

Database Providers

Sync Framework 2.0 introduces two new database providers, several important synchronization and management-related features, and significant performance improvements.

New Providers for SQL Server and SQL Server Compact

Sync Framework 2.0 includes two new database providers:

• SqlCeSyncProvider is used to synchronize SQL Server Compact databases.

  This provider can be used to synchronize with a central server but also has the ability to synchronize with other clients, which is not possible with SqlCeClientSyncProvider. This ability enables developers to target new scenarios such as a collaboration scenario in which teams of people need to synchronize among each another in the absence of a connection to a central server.

• SqlSyncProvider is used to synchronize any other edition of SQL Server, including SQL Server Express.

  This provider, which can be used as a server or a client, greatly reduces the barrier to synchronizing a SQL Server database. SqlSyncProvider is as capable as DbSyncProvider, but it requires significantly less code and less understanding of the queries that Sync Framework uses to synchronize data. DbSyncProvider is still appropriate for non-SQL Server databases.

Like all Sync Framework providers, these new providers can be used in topologies of any shape: client-server, peer-to-peer, and so on. For more information about both providers, see How to: Configure and Execute Collaborative Synchronization (SQL Server).

Robust Memory-Based Batching

Previous versions of Sync Framework and Sync Services for ADO.NET provided a way for developers to define their own batching logic, which was then called by the Sync Framework runtime. The drawbacks to this approach included: the inherent complexity associated with dividing changes into batches; excessive network roundtrips between the client and server; and the inability to solve resource contention issues because batches were based on the number of rows synchronized, rather than the amount of memory consumed by each batch.

Sync Framework 2.0 addresses all of these issues by providing a more complete and robust batching API. Developers no longer have to write batching logic themselves because the Sync Framework runtime divides changes into batches based on several properties in the API. Batches are now defined by memory consumption rather than the number of rows synchronized, which has eliminated out-of-memory issues for most common scenarios. For more information, see How to: Deliver Changes in Batches (SQL Server).

Provisioning and Management APIs

Provisioning and initialization activities that were previously exposed only through Visual Studio tooling have now been added to the database provider APIs. This includes the ability to provision an existing database by adding the change-tracking tables and triggers that are required by Sync Framework. It also includes the ability to start with an empty database, create the user schema, and provision that schema based on another server or client database that has already been provisioned. For more information, see How to: Configure and Execute Collaborative Synchronization (SQL Server).

Common tasks such as database backup and restore and metadata cleanup can now be accomplished directly through the API, eliminating the need for developers to implement this logic themselves. For more information, see How to: Backup and Restore a Database (SQL Server) and How to: Clean Up Metadata for Collaborative Synchronization (SQL Server)

Snapshot Initialization

Before a SQL Server Compact client database can begin to receive changes from another database, the client database must contain table schema and any initial data, as well as the change-tracking infrastructure that Sync Framework requires. Sync Framework provides two ways to initialize the database:

• Full initialization of the client database

  Full initialization is appropriate in some cases, but it is not ideal for scenarios with limited resources on the client. Creating the database schema from scratch and loading all the data over a slow network connection can result in long initial synchronization times and out-of-memory errors.

• Snapshot initialization of the client database by using a pre-existing client database

  Introduced in Sync Framework 2.0, snapshot initialization is designed to reduce the time that is required to initialize a client database. After one client database has been initialized by using full initialization, subsequent databases can be initialized by using a snapshot of this first client database. A snapshot is a specially-prepared SQL Server Compact database that contains table schema, data (optional), and change-tracking infrastructure. Snapshot initialization can improve initial synchronization times by an order of magnitude, and reduce memory contention significantly. For more information, see "Provisioning the Clients" in How to: Configure and Execute Collaborative Synchronization (SQL Server).

Flexibility Regarding Topology Shape

Previous versions of Sync Services for ADO.NET were tied to a specific topology shape in which many clients synchronized changes through a central server.

Because Sync Services for ADO.NET is now built on Sync Framework, developers can target a much wider range of scenarios. For example, developers can support collaboration scenarios that require the ability to synchronize changes between clients. In addition, developers can target a branch office scenario where a series of point-of-sale (POS) terminals are synchronized with a branch server which, in turn, is synchronized with a central corporate server.

Because the new database providers are built on Sync Framework, the stage is set to support synchronization of changes with new store types such as Azure SQL Data Services.

Performance Improvements

The new database providers in this release have been thoroughly tested in large scale out scenarios in which a single server supports thousands of clients with hundreds of concurrent synchronization operations. This testing resulted in a large number of internal performance improvements enable Sync Framework database providers to perform as well as other Microsoft technologies like Remote Data Access (RDA) while offering a wide range of capabilities that compete with end-to-end solutions like merge replication.

File synchronization provider

In addition to data conversion APIs that can be used for any type of custom provider, Sync Framework 2.0 also includes conversion APIs specifically for the file synchronization provider. For more information, see Synchronizing File Synchronization Provider with Other Providers, IFileDataRetriever (managed code) and IFileDataRetriever (unmanaged code).

Custom Providers

Sync Framework 2.0 includes significant improvements to the capabilities of standard custom providers, and introduces a new type of custom provider: the simple provider.

Simple Providers

The simple provider API reduces the amount of work required to develop providers. This is especially true when the data source has very few synchronization-related capabilities, such as change-tracking. This API enables a developer to write a provider without having to become a synchronization expert. The majority of the code for a simple provider is the code that is required to interact with the data source. For more information, see Implementing a Simple Custom Provider and Custom Provider Fundamentals.

Important New Types in Managed Code

• FullEnumerationSimpleSyncProvider

• AnchorEnumerationSimpleSyncProvider

• FullEnumerationContext

• AnchorEnumerationContext

• ItemEnumerationContext

For a complete list of types, see Microsoft.Synchronization.SimpleProviders.

Important New Interfaces in Unmanaged Code

• IFullEnumerationSyncProvider Interface

• IAnchorSyncProvider Interface

• IFullEnumerationCallback Interface

• IAnchorChangeDetectionCallback Interface

For a complete list of types, see Sync Framework Simple Provider Components.

Data Conversion Between Providers

In some scenarios, synchronization providers synchronize the same type of data (such as sales data), but the data format that each provider requires is different. To address this scenario, Sync Framework enables you to implement interfaces that convert data to the format that each provider requires. For more information, see Converting Data Between Providers.

New Types and Properties in Managed Code

• SyncDataConverter

• LocalDataConverter

• RemoteDataConverter

New Interfaces in Unmanaged Code

• ISyncDataConverter Interface

• ISyncDataConversionControl Interface

Filtering

Filters are used to control the data that is synchronized. Sync Framework 2.0 adds support for filters that control which change units are synchronized and for custom filters that are written by the developer. Sync Framework 2.0 also adds the ability for the providers to negotiate which filters are used during synchronization.

For more information, see Filtering Synchronization Data.

Change Unit Filtering

A change unit is part of an item that is synchronized, such as a phone number in a contacts item. Different replicas can have different representations of the same item, with some replicas offering a richer and more complete representation than others. For example, a synchronization community exchanges contact information, and defines change units for name, phone number, and address. One replica in the community is a mobile device that can only store name and phone number. Sync Framework caters to this scenario by enabling a provider to specify a change unit filter, which indicates that a replica is able to store only a subset of the data. The synchronization metadata and synchronization process have both been enhanced to handle this filtering efficiently.

New Types in Managed Code

• ChangeUnitListFilterInfo

New Interfaces and Methods in Unmanaged Code

• IChangeUnitListFilterInfo Interface

• IProviderFilteredSyncServices::CreateFilterInfo

Custom Filters

Custom filters are written by the developer and can be of any form. A filtered replica stores item data only for items that are in the filter, such as a media storage replica that stores only songs that are rated as three stars or better. As the rating on a song changes, an item may move in or out of the filter. A developer can define a custom filter that is used to control the item data that is stored on a filtered replica. A filter-tracking replica is another replica in the community that can identify which items are in the filter and which have moved in or out of the filter recently. A filter-tracking replica may store item data for items that are not in the filter. Sync Framework supports efficient synchronization from the filter-tracking replica to the filtered replica by sending only the items that are in the filter, along with information about the filter. Sync Framework also correctly calculates the knowledge and other metadata for the filter-tracking replica when changes are sent from the filtered replica to the filter-tracking replica.

Be aware that custom filters cannot be used by simple providers, by providers that report constraint conflicts, or by providers that use the change application service, or unexpected results may occur.

Important New Types in Managed Code

The provider implements the following types:

• IFilterTrackingProvider

• ISyncFilter

• IFilteredReplicaNotifyingChangeApplierTarget

• IFilterTrackingNotifyingChangeApplierTarget

Sync Framework implements the following types:

• CustomFilterInfo

• CombinedFilterInfo

• FilterKeyMap

For a complete list of types, see Microsoft.Synchronization.

Important New Interfaces in Unmanaged Code

The provider implements the following interfaces:

• IFilterTrackingProvider Interface

• ISyncFilter Interface

• IFilteredReplicaNotifyingChangeApplierTarget Interface

• IFilterTrackingNotifyingChangeApplierTarget Interface

Sync Framework implements the following interfaces:

• ICustomFilterInfo Interface

• ICombinedFilterInfo Interface

• IFilterKeyMap Interface

• IProviderCustomFilteredSyncServices Interface

• ISyncChangeWithFilterKeyMap Interface

• ISyncChangeBatchWithFilterKeyMap Interface

• IKnowledgeWithMarkers Interface

• IFilterTrackingSaveChangeContext Interface

For a complete list of interfaces, see Sync Framework Core Components.

Provider-Negotiated Filters

When a destination data source stores only a subset of the data available, it is more efficient if the source provider uses a filter to enumerate only the data that can be stored by the destination. Filter negotiation enables a destination provider to specify that the source provider should use one or more filters during change enumeration; the source provider can accept or reject a filter. If a source provider does not support any of the requested filters, the destination provider can choose to receive all the data and do the filtering itself. Sync Framework calls the providers appropriately to negotiate filter usage.

New Types in Managed Code

• ISupportFilteredSync

• IRequestFilteredSync

• FilterRequestCallback

New Interfaces in Unmanaged Code

• ISupportFilteredSync Interface

• IRequestFilteredSync Interface

• IFilterRequestCallback Interface

Conflict Handling

Sync Framework 2.0 adds enhanced support for constraint conflicts, for logged conflicts, and for implementing last-writer-wins conflict resolution.

Constraint Conflicts

Sync Framework 2.0 enhances support for constraint conflicts, which are conflicts that violate constraints that are put on items or change units, such as the relationship of folders or the location of identically named data within a file system. A destination provider can report a constraint conflict to Sync Framework, and use Sync Framework components to resolve the conflict and determine how to apply the resolution to the destination replica.

Be aware that constraint conflicts cannot be used by providers that use custom filters or the change application service, or unexpected results may occur.

For more information, see Detecting and Resolving Constraint Conflicts.

Important New and Updated Types in Managed Code

Destination providers implement the following new class:

• INotifyingChangeApplierTarget2

Synchronization applications implement new methods in the following class:

• SyncCallbacks

Sync Framework implements new members in the following classes:

• NotifyingChangeApplier

• SaveChangeWithChangeUnitsContext

• SaveChangeContext

• ItemChange

For a complete list of types, see Microsoft.Synchronization.

Important New Interfaces in Unmanaged Code

Destination providers implement the following new interface:

• ISynchronousNotifyingChangeApplierTarget2 Interface

Synchronization applications implement the following new interface:

• ISyncConstraintCallback Interface

Sync Framework implements the following new interfaces:

• IConstraintConflict Interface

• ISynchronousNotifyingChangeApplier2 Interface

• ISaveChangeContext2 Interface

• ISaveChangeWithChangeUnitsContext2 Interface

• ISyncChangeBatch2 Interface

• ISyncMergeTombstoneChange Interface

• IItemMetadata2 Interface

For a complete list of interfaces, see Sync Framework Core Components.

Logging Conflicts

It can be useful to save conflicts in a log so that they can be processed separately from the synchronization session, such as when a user needs to review conflicts and decide how to resolve them. Sync Framework 2.0 defines a set of conflict log interfaces and provides components that help manage conflicts in the log. Sync Framework also provides an implementation of the conflict log interfaces for replicas that do not contain a conflict log. This implementation operates in memory and is used to store temporary conflicts that may arise as result of constraint conflict handling. For more information, see Logging and Managing Conflicts.

New Types in Managed Code

Providers implement the following new classes:

• IConflictLogAccess

• IConflictLogWriter

Sync Framework implements the following new classes:

• LoggedConflict

• MemoryConflictLog

New Interfaces in Unmanaged Code

Providers implement the following new classes:

• IConflictLogAccess Interface

• IConflictLogWriter Interface

Sync Framework implements the following new classes:

• ILoggedConflict Interface

• IMemoryConflictLog Interface

Last-Writer-Wins Conflict Resolution

An application may want to resolve concurrency conflicts (in which an item is updated by more than replica) by keeping the most recently made change, regardless of where the change was made. Sync Framework 2.0 supports this resolution by providing a mechanism for an application to retrieve the time a change was made on the source replica and the time a change was made on the destination replica. The application can then compare the two times, and specify the conflict resolution action that applies the last change.

For more information, see Detecting and Resolving Concurrency Conflicts.

New Types in Managed Code

Providers implement the following new interface:

• ISupportLastWriteTime

New Interfaces in Unmanaged Code

Providers implement the following new interface:

• ISupportFilteredSync Interface

Tracing

Sync Framework enables you to trace the execution of several components, which is useful during application debugging. For most of the Sync Framework components, tracing is performed at the native code level by using the Event Tracing for Windows (ETW) infrastructure. Even if you develop against the managed version of an API, you still use ETW because the managed API is a thin wrapper over the native API. For more information, see Tracing Sync Framework Components.

Sync Framework database providers do provide managed tracing that is based on the .NET Framework implementation. For more information, see How to: Trace the Synchronization Process.

Change Application Service

Sync Framework includes a change applier implementation that most applications use to apply changes to a replica. In version 2.0, Sync Framework introduces the change application service, which performs the same actions as the change applier, but in a more granular way. A destination provider that requires greater flexibility than the standard change applier can use the change application service to perform only the set of actions that is required.

Be aware that the change application service cannot be used by providers that report constraint conflicts or use custom filters, or unexpected results may occur.

For more information, see Applying Changes by Using the Change Application Service.

New Types in Managed Code

• ChangeApplicationAction

• ChangeApplicationContext

• ChangeApplicationServices

New Interfaces and Enumeration in Unmanaged Code

• CHANGE_APPLICATION_ACTION Enumeration

• IChangeApplicationContext Interface

• IChangeApplicationServices Interface

Metadata Storage Service Serializer

The metadata storage service stores replica and item metadata in a lightweight database. The metadata is stored in a specific table schema and binary format that might change as new versions of Sync Framework are released. Additionally, custom provider fields in the database could change as a developer releases new versions of a particular provider. To enable greater interoperability between different versions, Sync Framework provides a canonical file format and a set of serialization interfaces, which are forward and backward compatible across a reasonable range of metadata changes between versions. For more information, see Accessing Metadata from Components with Different Versions and Upgrading the Metadata Store Version.

New Types in Managed Code

• SyncMetadataStoreSerializer

• SqlSyncMetadataStoreSerializer

• IProviderUpgradeCallback

New Interfaces in Unmanaged Code

• ISyncMetadataStoreSerializer Interface

• IProviderMetadataUpgradeCallback Interface

Provider Converters

Custom providers typically derive from IKnowledgeSyncProvider, but they can also derive directly from ISyncProvider. However, when an ISyncSession object is used to manage synchronization (which is typical), the provider must derive from IKnowledgeSyncProvider. To enable a provider derived from ISyncProvider to participate in a synchronization session, Sync Framework enables you to convert the provider to an IKnowledgeSyncProvider at runtime.

New Interfaces and Methods in Unmanaged Code

• IProviderConverter Interface

• IProviderConverterRegistration Interface

• IProviderSyncServices2::CreateProviderConverterRegistration

Knowledge Improvements

Sync Framework 2.0 improves the knowledge object for greater flexibility and efficiency.

Knowledge Structure

Sync Framework 2.0 changes the underlying structure of a knowledge object to a more flexible and efficient format, and defines new interfaces to access the new knowledge elements. For backward compatibility, the new knowledge objects also emulate the output of the Sync Framework 1.0 knowledge methods.

New and Updated Types in Managed Code

• KnowledgeFragmentBuilder

• KnowledgeFragmentInspector

• Range

• RangeSet

• SyncKnowledge

New Interfaces and Enumeration in Unmanaged Code

• ISyncKnowledge2 Interface

• SYNC_SERIALIZE Flags

• SYNC_SERIALIZATION_VERSION Enumeration

• ICoreFragmentInspector Interface

• ICoreFragment Interface

• IKnowledgeBuilder2 Interface

• IConstructReplicaKeyMap Interface

Knowledge Cookies

Sync Framework 2.0 adds knowledge cookies, which are lightweight, read-only representations of knowledge that can be used for fast comparisons when performance is especially important.

New Types and Members in Managed Code

• KnowledgeCookie

• KnowledgeCookieComparisonResult

• GetKnowledgeCookie

• Compare

New Enumeration and Methods in Unmanaged Code

• KNOWLEDGE_COOKIE_COMPARISON_RESULT Enumeration

• ISyncKnowledge2::GetKnowledgeCookie

• ISyncKnowledge2::CompareToKnowledgeCookie

Compatibility Levels

Sync Framework includes compatibility levels for metadata so that components of differing versions can continue to interoperate correctly. For more information, see Sync Framework Backwards Compatibility and Interoperability.

New Types and Members in Managed Code

• CompatibilityLevel

• CompatibilityLevel property of ChangeBatchBase and derived classes.

• CompatibilityLevel property of SyncKnowledge and derived classes.

New Enumeration and Methods in Unmanaged Code

• SYNC_SERIALIZATION_VERSION Enumeration

• ISyncChangeBatchBase2::SerializeWithOptions

• ISyncKnowledge2::SerializeWithOptions

• ISyncKnowledge2::GetMinimumSupportedVersion

Obsolete Interfaces

The following interfaces are obsolete and should not be used in new development. They continue to function as expected in Sync Framework 2.0, but might be removed in a later version.

Obsolete Interfaces in Unmanaged Code

• IAsynchronousDataRetriever Interface

• IAsynchronousNotifyingChangeApplier Interface

• IAsynchronousNotifyingChangeApplierTarget Interface

• IAsynchronousNotifyingChangeApplierTargetCallback Interface

• IDataRetrieverCallback Interface

See Also

Concepts

Microsoft Sync Framework
Benefits of Using Sync Framework
Selecting the Appropriate Sync Framework Components