私たちは WCF サービスを開発し、それを展開しようとしています。クライアントは で使用しますbasicHttpBindingが、社内チームは で使用しnamedPipesBindingます。
IIS 7 でホストするのと、Windows サービスでホストするのとのどちらがよいか、私たちは考えています。いくつかのテストを実行したところ、IIS でバインドを追加するときに、サービスの構成ファイルが更新されないことがわかりました。つまり、2 つの異なる場所で構成を維持する必要があります。論理的ではありませんよね？
また、WCF サービスが IIS のホストである場合、ベース アドレスが無視されることを StackOverflow で読みました ( <baseAddresses> に関する WCF サービス構成ファイルの質問を参照してください) 。
IISでのホスティングには、多くの長所と短所があります。
はい、IISはオンデマンドの読み込みを提供します-これはプラスまたはマイナスになります。リクエストが着信すると、ServiceHostが構築され、ホストされているサービスクラスがインスタンス化され、リクエストが処理されます。24時間稼働している必要はありません。しかし同時に、このセットアップではメッセージが届くたびに多くの時間と労力が必要になり、プログラマーとしてのあなたは実際にはサービスホストをあまり制御できません。
はい、IISでは、*。svcファイルが存在する仮想ディレクトリがアドレスを定義します。構成で明示的に定義されたアドレスはすべて無視されます。そして、多くの努力なしに、サービスアドレスのレイアウトを変更することはできません-それらは常にhttp：//servername/virtualdirectory/YourService.svc（.svc拡張子を含む）になります。
ServiceHostはすでに稼働しているため、セルフホスティングは多くの場合何倍も高速ですが、実際に稼働していることを確認するのはあなた次第です。メッセージが届くたびに「オンデマンド」の読み込みはありません。リクエストを処理できるかどうか。ただし、サービスホストは、いつどのように構築されるかなど、より詳細に制御でき、適切と思われるサービスアドレスを選択して定義できます。
私は個人的にほとんどの場合、セルフホスティングを使用することを選択します-テスト用のコンソールアプリ、本番用のNTサービスで。私には、それを行うためのより適切な方法であり、より制御された方法でもあるように思われます。あなたはもっと仕事をしなければなりません-しかしあなたはあなたが何をしているのかを正確に知っています。
マーク
marc_s は通常、私が完全に同意する優れた回答を提供しますが、この場合は同意しません。
WCF のセルフホスティングは、特に Microsoft がまもなくリリースする Dublin テクノロジを考えると、良い考えではありません。IIS 内でホストされると、WCF (および WF) アプリケーションの管理と操作がはるかに簡単になります。
さらに、オンデマンドの読み込みが可能です。
IIS7.5 (WS2008 R2) には常時オンのオプションがあります。
また、気になる場合は、簡単に URL 書き換えを行って .svc を省略できます。
興味深い一口-> このスレッドを読んだ後、Windows サービスを使用した WCF サービスのホスティングに関する MSDN の次の言葉に出くわしました。
以下は、Windows サービスの欠点の一部です。
•展開: サービスは、.NET Framework の Installutil.exe ユーティリティを使用するか、インストーラー パッケージのカスタム アクションを使用してインストールする必要があります。
機能の制限: Windows サービスには、高可用性、容易な管理、バージョン管理、および展開のシナリオをサポートするための、すぐに使用できる機能の限定されたセットがまだあります。基本的に、カスタム コードを使用してこれらの要件を自分でカバーする必要がありますが、たとえば、IIS にはこれらの機能のいくつかが既定で付属しています。Windows サービスは回復可能性といくつかのセキュリティ機能を追加しますが、それでも自分でいくつかの作業を行う必要があります。
http://msdn.microsoft.com/en-us/library/bb332338.aspx
...そして次のリンク:
ホスティング サービス: (優れた比較表)
http://msdn.microsoft.com/en-us/library/ms730158.aspx
それらの質問に答えるには：
いくつかのテストを実行したところ、IIS でバインドを追加するときに、サービスの構成ファイルが更新されないことがわかりました。つまり、2 つの異なる場所で構成を維持する必要があります。理屈じゃないですよね？
IIS を使用してサービスをホストする場合、App.config ファイルまたは web.config ファイルを構成して、IIS が何らかのバインディングを公開できるようにする必要があります。そのため、構成ファイルでは、許可するすべてのバインディングを wcf サービスに配置します。Http、net.tcp など...
IIS でこれらのアドレスを直接指定するため、バインドではアドレスを指定しません。
IIS では、Web サイトの詳細設定で利用可能なバインドを許可する必要があります。その後、Web サイトの「Web サービス」に新しいバインドを設定し、リッスンするすべてのバインドを追加して、アドレスを指定します。
アドレスは IIS で直接指定します。
例があります。
構成ファイル:
<services>
<service name="ServiceName">
<endpoint address=""
binding="basicHttpBinding"
bindingConfiguration="httpMode"
contract="IContract" />
<endpoint address=""
binding="netTcpBinding"
contract="IContract" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
IIS の高度な設定では、
有効なプロトコルの http,net.tcp
その後、IIS にバインドします。http のバインディングを正常に配置し、新しいバインディング net.tcp を追加します。バインディング構成で、ポートと仮想ディレクトリを次のように配置します。
8001:*
この設定により、仮想ディレクトリの 8001 ポートへのすべての接続が許可されます。
また、サーバーに「WCF アクティベーション (HTTP アクティベーションおよび非 HTTP アクティベーション)」機能をインストールする必要があります。
この質問に対する標準的な答えはありません。Cheeso からの回答には完全に同意しません (WCF のセルフホスティングは良い考えではありません)。
次のリンクを確認してください: ( http://msdn.microsoft.com/en-us/library/ms730158.aspx、http://msdn.microsoft.com/en-us/library/bb332338.aspx )制約:
多くの場合、「自己ホスティング」が最良の選択肢であることがわかります。
IIS は、アプリ ドメインの再読み込み、監視など、すぐに使用できる多くの機能を提供します。
これが、最初にこの質問に答える必要がある理由です。このすべての機能が必要ですか? そうでない場合は、Windows サービスを検討できます。
ここに回答がありますが、Q/Aスレッドリンクを投稿させていただきます。
IISでホストされているときにコードからWCFサービスを構成するにはどうすればよいですか？
そこでの私の回答（およびその中のリンク）にあるのは、サービスホストをWServiceにロードするかIISにロードするかにかかわらず、サービスホストを細かく制御できることです。
サービスの開始時に、IISにどのようなバインディングがあるかを問い合わせて、適切なエンドポイントを作成できます。Microsoft.Web.Administration名前空間を介してIIs構成を探します。
これが少し役立つことを願っています。