問題タブ [weboperationcontext]

純粋な WCF コンテキストでいくつかの RESTful サービスを実行しています (つまり、ASP.NET 互換性が有効になっていないため、HttpContext.Current使用できるオブジェクトがありません)。

サービスへの URL は、リクエストの開始時に を使用して書き換えられますIHttpModule(その時点では があり、HttpContextを使用して書き換えられます) 。これにより、URL から拡張子HttpContext.Current.RewritePathなどを取り除くことができます。.svc

ただし、WCF インフラストラクチャ内から要求された元の URL にアクセスする必要があります。またはクラスのどこかHttpContext.Current.Request.RawUrlに同等のものはありますか？を使用すると、元の URL ではなく、書き換えられた URL が返されます。OperationContextWebOperationContextWebOperationContext.Current.IncomingRequest.UriTemplateMatch.RequestUri

WCFサービスにこの属性がある場合：

次のシングルトンはどのように通話で機能しますか？

現在、WCF RESTful サービスを .NET 3.5 (スターター キット) から .NET 4 に移行しています。Visual Studio 2010 の WCF Rest サービス テンプレートを使用してプロジェクトを開始しました。 RequestInterceptor で行われます) ServiceAuthorizationManager を使用します。いくつかの作業と調査の後、私はそれを成し遂げました。しかし今、私は付随的な問題を抱えています。私のサービスは、HTTP ステータス コードと簡単な説明を使用して、処理エラーをクライアントにフィードバックしていました。サービスメソッドの多くのポイントで WebOperationContext を使用して、次のようにクライアントに問題を説明していました。

しかし、WCF 4 では、StatusCode のみが機能します - StatusDescription はサイレントに失敗します。理由がわかりません。私の唯一の推測は、この新しい WCF 4 シナリオでは WebOperationContext が機能しないということです。代わりに OperationContext を使用する必要がありますが、それも機能しません。次のメソッドは、ServiceAuthorizationManager を拡張するカスタム クラスで使用され、認証ダイジェストの形式が正しくないためにリクエストにアクセスできないことをクライアントに通知します。

ここで (WebOperationContext の代わりに) OperationContext を直接使用しても、StatusDescription は機能しません。

ここで何が欠けていますか？なぜこのような小さなことが .NET 3.5 から 4 に移行できるのでしょうか?

WCF プロジェクトで WebOperationContext.Current を使用しようとすると、Current が null になります。以下に例を示します。誰でもそれに光を当てることができますか？

Web フォーム - default.aspx:

//WCF インターフェイス

//WCF の実装

システム設定: ASP.NET 3.5

前もって感謝します。

私の質問の説明は次のように変更されます。

WCF プロジェクトで WebOperationContext.Current を使用しようとすると、Current が null になります。以下に例を示します。誰でもそれに光を当てることができますか？

私が必要としているのは、トークンに基づいて指定された作業を実行する既存のコードを作成する透過的な方法 (または既存のコードをほとんど変更しない方法) です。これが、ここで HttpModule が使用されている理由です。以下に示します。

//HttpModule: パイプラインで動作するトークンを挿入します。前述のように、HttpModule は既存のコードに最小限の変更を加えるために使用されます。

システム設定: ASP.NET 3.5

前もって感謝します。

WebOperationContext.Current.OutgoingResponse.StatusDescription プロパティのサーバー側で設定した値は無視されます。クライアント側はデフォルト メッセージを取得します。たとえば、404 コードの場合は Not Found、200 コードの場合は OK です。

単体テスト用にラッパーを介してWebOperationContextクラスをモックしています（Moqを使用）。しかし、メッセージ生成のために、モックされたコンテキストでWebOperationContextクラスからCreateTextResponse（...）メソッドを実行する必要があります。その方法を教えてください。

編集：以下は、WebOperationContextに使用している現在のモックです。ただし、CreateTextResponse/CreateStreamResponseを実装できません。

私はBeginX()というサービスメソッドを持つRESTful WCFサービスを持っています

BeginX 内で、静的ヘルパー クラスで静的 Validate 関数を呼び出します。静的な Validate メソッド内で、WebOperationContext.Current.OutgoingResponse.StatusCode = blah を呼び出すことはできますか?

現在のコンテキストがサービスの静的メソッド内から呼び出された場合、どのような動作が予想されますか?

(プロトタイプを作成しようとしましたが、コンソール アプリで実行されるインプロセス WCF サービスから取得しようとすると、WebOperationContext を取得できないようです)

WCFMockを使用して、WebサービスのWebOperationContextをモックしています。唯一の使用法は、カスタムHTTPヘッダーをWebOperationContext.Current.OutgoingResponse.Headersコレクションに追加することです。Moqを使用してこれを確認することはできません。私がすでに試したこと：

• Addメソッドが呼び出されているかどうかを確認します。追加は仮想ではないため、これは失敗します
• MockedWebOperationContext.Currentから直接ヘッダーにアクセスしてみてください。これは常に数がゼロです

カスタムヘッダーが追加されたことを単体テストケースで確認するにはどうすればよいですか？

NUnit を使用してメソッドをテストするときに、WCF サービス メソッドで WebOperationContext が null であることを回避するにはどうすればよいですか

NUnit を使用して、WCF メソッドによって返されるデータをテストする単体テスト プロジェクトがあります。

次に、次のようなテストメソッドがあります

ただし、テスト中にエラーが発生します

SampleServiceメソッドのWebOperationContextについて。

値が適切に読み取られ、OutgoingReponse.ContentType が目的の形式と一致することをテストするために、Accept 値を割り当てるヘッダーを使用して、WebOperationContext、特に IncomingRequest をモックする必要があります。私は WCFMock を使用しており、一般的なテストではすべて問題ありませんでしたが、着信応答をモックするために何をする必要があるのか​​ 理解できません。

Accept プロパティは読み取り専用であるため、直接割り当てることはできません。System.SericeModel.Web.IncomingWebRequestContext から継承しているため、セッターを WCFMock.IncomingWebRequestContextWrapper に追加しようとしました。

だから、このようなものが望まれるでしょう

}

WebRequest を完全にモックする必要があるのではないかと心配しており、可能であればそれを避けたいと考えています。