これはあなたの質問の周辺ですが、戻るのに10分以上かかるメソッドからの非同期コールバックを検討し、プロセスを別のスレッドで実行することを検討しましたか?サービスコールを同期的に10分間待機させることは実際には良い習慣ではなく、問題を解決する可能性がありますが、サービスはとにかく一度に複数の発信者を許可する必要があります(WCFサービスは数千の同時リクエストを受け取ります)。
WCFを呼び出すときは、同期的に呼び出すか非同期的に呼び出すかを選択できます。同期呼び出しは、同じ操作で応答が呼び出し元に返送されるのを待ちます。呼び出し元では、「myresult = svc.DoSomething()」のようになります。非同期呼び出しでは、呼び出し元はサービスが完了したときに呼び出す関数をサービスに提供しますが、応答を待ちません。発信者は応答を待っている間ブロックせず、ビジネスを開始します。
コールバックはDoSomethingCompletedEventArgsを取ります:void myCallback(object sender、DoSomethingCompletedEventArgs e){var myResult = e.Result; //次に、以前の結果を使用します。}
コールバック関数をイベントハンドラーのように登録します。svc.DoSomethingCompleted+=myCallback; 次に、svc.DoSomethingAsync()。そのステートメントには戻り値がないことに注意してください。サービスは、完了時にmyCallBackを実行し、結果を渡します。(SilverlightからのすべてのWCF呼び出しは非同期である必要がありますが、他のクライアントの場合、この制限はありません)。
これは、少し異なる方法を詳細に示すコードプロジェクトの記事です。
http://www.codeproject.com/Articles/91528/How-to-Call-WCF-Services-Synchronously-and-Asynchr
これにより、10分以上のプロセス中にクライアントがブロックされるのを防ぎますが、サービス自体の機能を実際に変更することはありません。
さて、私が言及したことの2番目の部分は、サービス内とは別のスレッドで10分以上のプロセスを開始することでした。サービスメソッド自体は非常に薄く、他のライブラリの機能を呼び出すだけである必要があります。時間がかかる関数は、理想的には独自のスレッドで呼び出され(たとえば、完了時にコールバックをサービス側で登録するバックグラウンドワーカー)、進行状況を追跡するための何らかの永続的なシステムを備えている必要があります。クライアントに戻る必要のある結果。私の場合は、プロセスのリクエストをデータベースに登録し、そのデータベースを完了して更新します。次に、クライアントは定期的に単純なポーリングを開始して、プロセスが完了したかどうかを確認し、結果を取得します。
これらのトピックは、私がここで深く掘り下げるには本当に大きすぎます。BackgroundWorkerを使用してマルチスレッド操作を調査することをお勧めします。