クライアント/サーバーアプリケーションで長時間実行されるプロセスを処理する方法を設計および実装する必要があります。通常の長時間実行プロセスには2〜3分かかる場合があります。また、その間にUIに進行状況を報告し、UIの応答性を維持する必要があります。
これらを念頭に置いて、いくつかの解決策を考えました。
サーバー側プロセスを開始し、割り当てられたLRPID（長時間実行プロセスID）を返すプロセスを開始し、そのLRPIDを使用してクライアントから定期的にポーリングする1つの非同期要求。（長所：導入が簡単で、ファイアウォールが混乱することはありません。短所：エレガントでない、リソースを消費するなど）
デュプレックスバインディング（NetTcpBindingなど）を使用し、進行中にサーバーからのコールバックを開始します（Pro：エレガント、効率的、Con：展開の悪夢）
[あなたの提案？？？]
これについてどう思いますか？
これは、SilverlightアプリケーションのWCF進行状況インジケーターを作成する方法に関するDanWahlinによる投稿です。これはいくつかの助けになるはずです。
クライアントのファイアウォールなどについて心配する必要がない場合は、おそらく最初のソリューションを使用して、UIスレッドをブロックしないように、 BackGroundWorkerを使用して呼び出しを行います。私は最近、レポートを生成するリクエストがキューに入れられ、実行されると取得されるアプリに対してこれを行いました。それはうまくいくようです。
（WCFバインディングを変更せずに）別の方法は、WPFクライアントでWebBrowserコントロールを使用し、SignalRを使用してサーバーからそのコントロールに進行状況メッセージを投稿することです。
WebBrowserコントロールで発生するjavascriptエラーを回避するために（デフォルトでは、jQuery.jsと互換性がないように見えるInternet Explorerバージョン7を使用しているように見えるため）、クライアントのレジストリにキーを追加する必要があることに注意してください。 IE10以降を使用するようにクライアントアプリのデフォルトを変更するマシン-http://weblog.west-wind.com/posts/2011/May/21/Web-Browser-Control-Specifying-the-IE-Versionを参照してください）。これは展開の邪魔になる可能性があります（レジストリキーを追加するには、管理者権限が必要なようです（たとえば、64ビットのWindows 8.1 PCの場合）。また、長時間実行されているWCFメソッドを別のスレッドで呼び出す必要があるようです。そうしないと、WebBrowserコントロールは、受信しているSignalRメッセージを表示するように表示を更新しないようです。（UIスレッドは、WCF呼び出しが終了するまで待機する必要があるため、これは理にかなっています）。
しかし、新しいツール（SignalR）を使用した代替アプローチとして言及します:)