次の方法で共有


WCF サービス Services-Hosted インターネット情報の展開

インターネット インフォメーション サービス (IIS) でホストされる Windows Communication Foundation (WCF) サービスの開発と展開は、次のタスクで構成されます。

  • IIS、ASP.NET、WCF、および WCF アクティブ化コンポーネントが正しくインストールされ、登録されていることを確認します。

  • 新しい IIS アプリケーションを作成するか、既存の ASP.NET アプリケーションを再利用します。

  • WCF サービスの .svc ファイルを作成します。

  • サービスの実装を IIS アプリケーションにデプロイします。

  • WCF サービスを構成します。

IIS でホストされる WCF サービスを作成する詳細なチュートリアルについては、「 方法: IIS で WCF サービスをホストする」を参照してください。

IIS、ASP.NET、WCF が正しくインストールされ、登録されていることを確認する

IIS でホストされる WCF サービスが正しく機能するためには、WCF、IIS、および ASP.NET をインストールする必要があります。 WCF (.NET Framework の一部として)、ASP.NET、IIS をインストールする手順は、オペレーティング システムによって異なります。 WCF と .NET Framework のインストールの詳細については、「 開発者向けの .NET Framework のインストール」を参照してください。 Windows 10 に IIS をインストールするには、コントロール パネル[プログラムと機能] を開き、[Windows の機能を有効または無効にする] を選択します。 Windows 機能で、[インターネット インフォメーション サービス] を選択し、[OK] を選択します。

IIS が強調表示されている Windows 機能

他のオペレーティング システムに IIS をインストールする手順については、「 Windows Vista および Windows 7 に IIS をインストールする」および「WindowsServer 2012 R2 に IIS 8.5 をインストールする」を参照してください。

IIS がコンピューターに既に存在する場合、.NET Framework のインストール プロセスによって WCF が IIS に自動的に登録されます。 .NET Framework の後に IIS をインストールする場合は、WCF を IIS と ASP.NET に登録するための追加の手順が必要です。 これは、オペレーティング システムに応じて次のように実行できます。

新しい IIS アプリケーションを作成するか、既存の ASP.NET アプリケーションを再利用する

IIS でホストされる WCF サービスは、IIS アプリケーション内に存在する必要があります。 WCF サービスのみをホストする新しい IIS アプリケーションを作成できます。 または、既に 2.0 コンテンツ ASP.NET ホストしている既存のアプリケーション (.aspx ページや ASP.NET Web サービス [ASMX] など) に WCF サービスをデプロイすることもできます。 これらのオプションの詳細については、WCF サービスと ASP.NET の「ASP.NET を使用した WCF サイド バイ サイドのホスト」および「ASP.NET 互換モードでの WCF サービスのホスト」セクションを 参照してください

IIS 6.0 以降のバージョンでは、分離されたオブジェクト指向プログラミング アプリケーションが定期的に再起動されることに注意してください。 既定値は 1740 分です。 サポートされる最大値は 71,582 分です。 この再起動は無効にすることができます。 このプロパティの詳細については、 PeriodicRestartTime を参照してください。

WCF サービスの .svc ファイルを作成する

IIS でホストされる WCF サービスは、IIS アプリケーション内の特別なコンテンツ ファイル (.svc ファイル) として表されます。 このモデルは、ASMX ページが IIS アプリケーション内で .asmx ファイルとして表される方法に似ています。 .svc ファイルには WCF 固有の処理ディレクティブ (@ServiceHost) が含まれています。これにより、WCF ホスティング インフラストラクチャは、受信メッセージに応答してホストされたサービスをアクティブ化できます。 .svc ファイルの最も一般的な構文は、次のステートメントにあります。

<% @ServiceHost Service="MyNamespace.MyServiceImplementationTypeName" %>

@ServiceHost ディレクティブと 1 つの属性 (Service) で構成されます。 Service属性の値は、サービス実装の共通言語ランタイム (CLR) 型名です。 このディレクティブの使用は、基本的に次のコードを使用してサービス ホストを作成することと同じです。

new ServiceHost( typeof( MyNamespace.MyServiceImplementationTypeName ) );

サービスのベース アドレスの一覧の作成など、追加のホスティング構成も実行できます。 カスタム ServiceHostFactory を使用して、カスタム ホスティング ソリューションで使用するディレクティブを拡張することもできます。 WCF サービスをホストする IIS アプリケーションは、 ServiceHost インスタンスの作成と有効期間を管理する責任を負いません。 マネージド WCF ホスティング インフラストラクチャは、.svc ファイルに対する最初の要求を受信したときに、必要な ServiceHost インスタンスを動的に作成します。 インスタンスは、コードによって明示的に閉じられるか、アプリケーションがリサイクルされるまで解放されません。

.svc ファイルの構文の詳細については、 @ServiceHostを参照してください。

サービス実装を IIS アプリケーションに展開する

IIS でホストされている WCF サービスでは、ASP.NET 2.0 と同じ動的コンパイル モデルが使用されます。 ASP.NET と同様に、IIS でホストされる WCF サービスの実装コードは、次のようにさまざまな場所に複数の方法で展開できます。

  • グローバル アセンブリ キャッシュ (GAC) またはアプリケーションの \bin ディレクトリにあるプリコンパイル済み .dll ファイルとして。 プリコンパイル済みバイナリは、クラス ライブラリの新しいバージョンがデプロイされるまで更新されません。

  • アプリケーションの \App_Code ディレクトリにあるコンパイルされていないソース ファイル。 このディレクトリにあるソース ファイルは、アプリケーションの最初の要求を処理するときに動的に必要です。 \App_Code ディレクトリ内のファイルを変更すると、次の要求を受信したときにアプリケーション全体がリサイクルされ、再コンパイルされます。

  • .svc ファイルに直接配置されたコンパイルされていないコード。 実装コードは、@ServiceHost ディレクティブの後に、サービスの .svc ファイル内にインラインで配置することもできます。 インライン コードを変更すると、次の要求を受信したときにアプリケーションがリサイクルされ、再コンパイルされます。

ASP.NET 2.0 コンパイル モデルの詳細については、「 ASP.NET コンパイルの概要」を参照してください。

WCF サービスを構成する

IIS でホストされる WCF サービスは、その構成をアプリケーション Web.config ファイルに格納します。 IIS でホストされるサービスでは、IIS の外部でホストされている WCF サービスと同じ構成要素と構文が使用されます。 ただし、次の制約は IIS ホスティング環境に固有です。

  • IIS でホストされるサービスのベース アドレス。

  • IIS の外部で WCF サービスをホストするアプリケーションは、一連のベース アドレス URI を ServiceHost コンストラクターに渡すか、サービスの構成で <host> 要素を指定することで、ホストするサービスのベース アドレスを制御できます。 IIS でホストされているサービスには、ベース アドレスを制御する機能がありません。IIS でホストされるサービスのベース アドレスは、その .svc ファイルのアドレスです。

IIS-Hosted サービスのエンドポイント アドレス

IIS でホストされている場合、エンドポイント アドレスは常に、サービスを表す .svc ファイルのアドレスに対する相対アドレスと見なされます。 たとえば、WCF サービスのベース アドレスが次のエンドポイント構成で http://localhost/Application1/MyService.svc 場合です。

<endpoint address="anotherEndpoint" />

これにより、 http://localhost/Application1/MyService.svc/anotherEndpointで到達できるエンドポイントが提供されます。

同様に、相対アドレスとして空の文字列を使用するエンドポイント構成要素は、 http://localhost/Application1/MyService.svcで到達可能なエンドポイント (ベース アドレス) を提供します。

<endpoint address="" />

IIS でホストされるサービス エンドポイントには、常に相対エンドポイント アドレスを使用する必要があります。 完全修飾エンドポイント アドレス (たとえば、 http://localhost/MyService.svc) を指定すると、エンドポイント アドレスがエンドポイントを公開しているサービスをホストする IIS アプリケーションを指していない場合、サービスのデプロイでエラーが発生する可能性があります。 ホストされるサービスに相対エンドポイント アドレスを使用すると、これらの潜在的な競合を回避できます。

利用可能なトランスポート

IIS 5.1 および IIS 6.0 でホストされる WCF サービスは、HTTP ベースの通信の使用に制限されます。 これらの IIS プラットフォームでは、HTTP 以外のバインドを使用するようにホステッド サービスを構成すると、サービスのアクティブ化中にエラーが発生します。 IIS 7.0 の場合、サポートされているトランスポートには、既存の MSMQ アプリケーションとの下位互換性のために HTTP、Net.TCP、Net.Pipe、Net.MSMQ、msmq.formatname が含まれます。

HTTP トランスポート セキュリティ

IIS でホストされる WCF サービスは、サービスを含む IIS 仮想ディレクトリがこれらの設定をサポートしている限り、HTTP トランスポート セキュリティ (たとえば、基本認証、ダイジェスト認証、Windows 統合認証などの HTTPS および HTTP 認証スキーム) を利用できます。 ホストされるエンドポイントのバインドの HTTP トランスポート セキュリティ設定は、それを含む IIS 仮想ディレクトリのトランスポート セキュリティ設定と一致する必要があります。

たとえば、HTTP ダイジェスト認証を使用するように構成された WCF エンドポイントは、HTTP ダイジェスト認証を許可するように構成された IIS 仮想ディレクトリに存在する必要があります。 IIS 設定と WCF エンドポイント設定の組み合わせが一致しない場合、サービスのアクティブ化中にエラーが発生します。

こちらも参照ください