私は現在、「ときどき切断される」モードで動作する必要があるスマートクライアントアプリ（WPF）を設計しています。オフラインのシナリオでは、次の使用を検討しています。
スマートクライアントアプリをXCOPYでデプロイ可能、自動更新、および管理者権限なしでインストールできるようにしたいことを述べておく必要があります。基本的には、ClickOnceでデプロイされたアプリです。私の知る限り、これは、管理者権限を必要とするクライアントに登録する必要のあるCOMが実装に含まれているため、MicrosoftSyncFrameworkが停止していることを意味します。ClickOnceアプリからMSFをXCOPYでデプロイして実行することは可能ですか？データ同期に関する他のアイデアはありますか？
なぜ同期フレームワークを使用するのですか？それがうまく機能することを念頭に置いている特定のユースケースはありますか？
DSAはサービス呼び出しを積み上げ、接続が利用可能になると、関連するサービスへの呼び出しを開始します。それはあなたが本当に同期できるものではありません。
私が最後の2つのSmartClientアプリで行ったことは、参照データなどの「同期」のための単純な手動実装でした。同期されるものはすべてDSAを経由しません（同期は論理的に接続モードでのみ発生します）。
同期が必要な各「データ」のクライアント側-最後に同期された日時を保存します。同期するために、ピース「タイプ」を最後に更新された時刻と送信し、サーバーは新しいアイテムと更新されたアイテムのデルタを送り返します。削除されたアイテムのケースを処理しませんが、それは一般的にそれをトリッキーにします。
私の現在のアプリでは、これで十分なので、アプリの起動時にこのデータを同期しますが、以前のシステムでは、各「ピース」を更新する必要があるかどうかを1分ごとにチェックするバックグラウンドスレッドを実行していました（たとえば、重要でない場合は24時間ごと）アイテム、重要なアイテムの場合は1時間）、必要に応じて非同期で同期を開始します。
クライアント側とサーバー側で少し余分な作業が必要ですが、正直なところ、外部フレームワークを取得して実行するよりも作業が少ないと思います。特に、そのフレームワークをClickonce展開パッケージ内に展開できない場合はそうです。
アプリを「ときどき接続」することで、システムの複雑さが大幅に増します...幸運を祈ります！
私が知る限り、MSFには管理者インストールが必要です。これは、以前のバージョンのSync for ADO.NETにはなかったように、私を悩ませます。
こんにちは、少し遅すぎるかもしれませんが、ブートストラッパーパッケージを使用することもできます。" ... Visual Studio Setup＆DeploymentプロジェクトおよびClickOnceアプリケーションで使用してSyncFramework2.0コンポーネントを再配布できるSyncFramework2.0ブートストラッパーパッケージサンプル... "（http://www.microsoft.com/downloads/details.aspx ？familyid = 109DB36E-CDD0-4514-9FB5-B77D9CEA37F6＆displaylang = en）