デフォルトのエンドポイント要素が見つかりませんでした

VS2008 / .NET 3.5ソリューションのWebサービスにプロキシを追加しました。クライアント.NETを構築すると、次のエラーがスローされます。

ServiceModelクライアント構成セクションで、コントラクト 'IMySOAPWebService'を参照するデフォルトのエンドポイント要素が見つかりませんでした。これは、アプリケーションの構成ファイルが見つからなかったか、このコントラクトに一致するエンドポイント要素がクライアント要素で見つからなかったためである可能性があります。

このエラーを検索すると、コントラクトで完全な名前空間を使用するように指示されます。これが完全な名前空間を持つ私のapp.configです：

<client>
  <endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
            binding="basicHttpBinding" bindingConfiguration="IMySOAPWebServicebinding"
            contract="Fusion.DataExchange.Workflows.IMySOAPWebService" name="IMySOAPWebServicePort" />
</client>

私はローカルでXPを実行しています（Googleのヒットの多くがwin2k3について言及しているので、これについて言及します）app.configはapp.exe.configにコピーされるため、これも問題ではありません。

手がかりはありますか？

「このエラーは、クラスライブラリでサービスを呼び出し、別のプロジェクトからクラスライブラリを呼び出す場合に発生する可能性があります。」

この場合、WinAppの場合はメインプロジェクトのapp.configに、Webアプリの場合はweb.configにWS構成設定を含める必要があります。これは、PRISMとWPF / Silverlightを使用する場合でも同じです。

私は自分でバインディングとエンドポイントアドレスのインスタンスを作成することでこれを解決しました（他の人が示唆していると思います）。構成ファイルに新しい設定を追加したくなかったためです（これは、広く使用されている既存のライブラリコードの代わりです）、以前は古いWebサービス参照などを使用していたため）、どこにでも新しい構成設定を追加せずにこれをドロップできるようにしたかったのです。

var remoteAddress = new System.ServiceModel.EndpointAddress(_webServiceUrl);

using (var productService = new ProductClient(new System.ServiceModel.BasicHttpBinding(), remoteAddress))
{
    //set timeout
    productService.Endpoint.Binding.SendTimeout = new TimeSpan(0,0,0,_webServiceTimeout);

    //call web service method
    productResponse = productService.GetProducts();
} 

編集する

httpsを使用している場合BasicHttpsBindingは、ではなくを使用する必要がありますBasicHttpBinding。

いくつかのオプションをテストした後、私は最終的にこれを使用して解決しました

contract = "IMySOAPWebService"

つまり、設定に完全な名前空間がありません。何らかの理由で氏名が正しく解決されなかった

これと同じ問題が発生しました。Web REFERENCEの場合、コンストラクターの最初のパラメーターとしてURLを指定する必要があることがわかります。

new WebService.WebServiceSoapClient("http://myservice.com/moo.aspx");

新しいスタイルのWebサービスリファレンスの場合、構成内のエンドポイントエントリを参照する名前を指定する必要があります。

new WebService.WebServiceSoapClient("WebServiceEndpoint");

Web.configまたはに対応するエントリがありApp.configます：

<client>
      <endpoint address="http://myservice.com/moo.aspx"
        binding="basicHttpBinding" 
        bindingConfiguration="WebService"
        contract="WebService.WebServiceSoap"
        name="WebServiceEndpoint" />
    </client>
  </system.serviceModel>

「古いプログラムで機能した」というトンネルのビジョンを削除するのはかなり大変です...

私はこのような状況がありました

• どこかでホストされているWCFサービス
• 主なプロジェクト
• WCFサービスへのサービス参照を持つ「クラスライブラリ」タイプのコンシューマープロジェクト
• メインプロジェクトはコンシューマープロジェクトからメソッドを呼び出します

これで、コンシューマプロジェクトに関連するすべての構成設定が <system.serviceModel> app.configのタグに含まれていますが、それでも上記と同じエラーがスローされていました。

私が行ったのは<system.serviceModel>、メインプロジェクトのapp.configファイルに同じタグを追加することだけです。

本当の問題は、私の場合は、間違った構成ファイルを読み取っていたことです。コンシューマーのapp.configの代わりに、メインプロジェクトの構成を参照していました。それを理解するのに2時間かかりました。

「このエラーは、クラスライブラリでサービスを呼び出し、別のプロジェクトからクラスライブラリを呼び出す場合に発生する可能性があります。」

「この場合、winappの場合はWS構成設定をメインプロジェクトのapp.configに、Webアプリの場合はweb.configに含める必要があります。これは、PRISMとWPF / Silverlightを使用する場合でも実行できる方法です。」

はい。ただし、メインプロジェクト（Orchard CMSなど）を変更できない場合は、プロジェクトにWCFサービス構成を保持できます。

クライアント生成メソッドを使用してサービスヘルパーを作成する必要があります。

public static class ServiceClientHelper
{
    public static T GetClient<T>(string moduleName) where T : IClientChannel
    {
        var channelType = typeof(T);
        var contractType = channelType.GetInterfaces().First(i => i.Namespace == channelType.Namespace);
        var contractAttribute = contractType.GetCustomAttributes(typeof(ServiceContractAttribute), false).First() as ServiceContractAttribute;

        if (contractAttribute == null)
            throw new Exception("contractAttribute not configured");

        //path to your lib app.config (mark as "Copy Always" in properties)
        var configPath = HostingEnvironment.MapPath(String.Format("~/Modules/{0}/bin/{0}.dll.config", moduleName)); 

        var configuration = ConfigurationManager.OpenMappedExeConfiguration(new ExeConfigurationFileMap { ExeConfigFilename = configPath }, ConfigurationUserLevel.None);
        var serviceModelSectionGroup = ServiceModelSectionGroup.GetSectionGroup(configuration);

        if (serviceModelSectionGroup == null)
            throw new Exception("serviceModelSectionGroup not configured");

        var endpoint = serviceModelSectionGroup.Client.Endpoints.OfType<ChannelEndpointElement>().First(e => e.Contract == contractAttribute.ConfigurationName);
        var channelFactory = new ConfigurationChannelFactory<T>(endpoint.Name, configuration, null);
        var client = channelFactory.CreateChannel();
        return client;
    }
}

そしてそれを使う：

using (var client = ServiceClientHelper.GetClient<IDefaultNameServiceChannel>(yourLibName)) {
                ... get data from service ...
            }

この記事の詳細をご覧ください。

ここでいくつかの応答は、クラスファイルからサービスを参照するという非常に曖昧なエラーに直面しているときに正しい解決策を見つけました。サービス構成情報をコンソールまたはWindowsアプリのapp.config web.configにコピーします。これらの答えはどれも、何をコピーするかを示しているようには見えません。修正してみましょう。

これは、 "TranslationServiceOutbound"というサービスのこのクレイジーなエラーを回避するために、クラスライブラリの構成ファイルからコンソールアプリの構成ファイルにコピーしたものです。

基本的に、すべてをsystem.serviceModelセクション内に配置します。

  <system.serviceModel>
<bindings>
  <basicHttpBinding>
    <binding name="BasicHttpBinding_ITranslationServiceOutbound" />
  </basicHttpBinding>
</bindings>
<client>
  <endpoint address="http://MyHostName/TranslationServiceOutbound/TranslationServiceOutbound.svc"
    binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ITranslationServiceOutbound"
    contract="TranslationService.ITranslationServiceOutbound" name="BasicHttpBinding_ITranslationServiceOutbound" />
</client>

これは私を狂わせた。

Silverlight 3 Prism（CAB）をWCFで使用しています

PrismモジュールでWCFサービスを呼び出すと、同じエラーが発生します。

サービスモデルクライアントの構成セクションで、コントラクト 'IMyService'を参照するデフォルトのエンドポイント要素が見つかりませんでした。これは、アプリケーションの構成ファイルが見つからなかったか、このコントラクトに一致するエンドポイント要素がクライアント要素で見つからなかったことが原因である可能性があります

シェルの.xapファイルでServiceReferences.ClientConfigファイルを探すのではなく、モジュールのServiceReferences.ClientConfigファイルを探すことがわかりました。エンドポイントを追加し、Silverlightシェルアプリケーションの既存のServiceReferences.ClientConfigファイルにバインドします（それは独自のWCFサービスを呼び出します）。

次に、シェルアプリを再構築して、WebプロジェクトのClientBinフォルダー用の新しい.xapファイルを生成する必要がありました。

これで、次のコード行が最終的に機能します。

MyServiceClient myService = new MyServiceClient();

ASP.NETアプリケーション内で、binフォルダー内の参照される.dllファイルとしてASP.NETアプリケーションに追加されるクラスライブラリにWCFサービスが追加されている場合に、このエラーが発生しました。エラーを解決するには、WCFサービスを参照するクラスライブラリ内のapp.configファイルの構成設定を、ASP.NETサイト/アプリのweb.config設定にコピーする必要があります。

（クラスライブラリインターフェイスを使用していたときにクライアントUIのApp.configにコピーするのと同じように）バインディングの名前の前にサービス参照の名前を付ける必要がありました（私は ServiceReference以下にあります）。

例えば：

<endpoint address="http://localhost:4000/ServiceName" binding="basicHttpBinding"
      bindingConfiguration="BasicHttpBinding_ISchedulerService"
      contract="ServiceReference.ISchedulerService" 
      name="BasicHttpBinding_ISchedulerService" />

生成されたデフォルトの代わりに：

<endpoint address="http://localhost:4000/ServiceName" binding="basicHttpBinding"
      bindingConfiguration="BasicHttpBinding_ISchedulerService"
      contract="ISchedulerService" 
      name="BasicHttpBinding_ISchedulerService" />

同じ問題がありましたが、コントラクトの名前空間を変更してもうまくいきませんでした。そこで、.Net 3.5サービスリファレンスではなく、.Net 2スタイルのWebリファレンスを試しました。うまくいきました。

Visual Studio 2008でWeb参照を使用するには、[サービス参照の追加]をクリックし、ダイアログボックスが表示されたら[詳細設定]をクリックします。その中に、Service参照の代わりにWeb参照を使用できるオプションがあります。

サービスを使用する非ライブラリアプリケーションのユニットテストを行うと、この問題が発生する可能性があります。

他の人が入力した情報は、この根本的な原因に対処しています。自動テストケースを記述しようとしていて、テストしているユニットが実際にサービスインターフェイスを呼び出す場合は、テストプロジェクトにサービス参照を追加する必要があります。これは、ライブラリタイプのエラーを使用するアプリケーションのフレーバーです。インターフェイスを使用するコードがライブラリにないため、すぐにはわかりませんでした。ただし、テストが実際に実行されるときは、テスト対象のアセンブリではなく、テストアセンブリから実行されます。

単体テストプロジェクトにサービス参照を追加すると、問題が解決しました。

ユニットテストの状況です。app.configファイルを単体テストプロジェクトにコピーしました。そのため、単体テストプロジェクトにはエンドポイント情報も含まれています。

私は一度この問題に直面しました。それは私がまだWCFサービスを使用するインターフェイスを開発していたからです。テストアプリケーションを構成し、開発を続けました。その後、開発中に、サービスの名前空間の一部を変更しました。そこで、WCFクラスと一致するようにweb.configで「system.serviceModel-> client-> endpoint-> contract」をダブルチェックしました。その後、問題は解決されます。

構成内の名前空間は、クライアントのデフォルトの名前空間（プロジェクトプロパティで構成されている）の後の残りの名前空間パスを反映する必要があります。あなたの投稿された回答に基づいて、私の推測では、クライアントは「Fusion.DataExchange.Workflows」名前空間にあるように構成されていると思います。クライアントコードを別の名前空間に移動した場合、残りの名前空間パスと一致するように構成を更新する必要があります。

同じ問題があります。クラスライブラリでWCFサービスを使用し、Windowsアプリケーションプロジェクトからクラスライブラリを呼び出していますが、Windowsアプリケーションプロジェクトの<system.serviceModel>構成ファイルの変更<system.serviceModel>をクラスライブラリのapp.Configファイルと同じに忘れています。
解決策：クラスライブラリのwcf構成と同じように外部プロジェクトの構成を変更します。

こんにちは私は同じ問題に遭遇しましたが、最善の解決策は.NETにクライアント側の構成を構成させることです。http：/namespace/service.svc？wsdl = wsdl0のクエリ文字列を使用してサービス参照を追加すると、クライアント側に構成エンドポイントが作成されないことがわかります。しかし、？wsdl-wsdl0を削除して、http：/namespace/service.svcというURLのみを使用すると、クライアント構成ファイルにエンドポイント構成が作成されます。略して "？WSDL = WSDL0"を削除します。

サービスクライアント宣言行をクラスフィールドとして配置しないでください。代わりに、使用された各メソッドでインスタンスを作成してください。したがって、問題は修正されます。サービスクライアントインスタンスをクラスフィールドとして作成すると、設計時エラーが発生します。

PRISMフレームワークを使用してWPFアプリケーションを使用している場合、構成は起動プロジェクト（つまり、ブートストラップが存在するプロジェクト）に存在する必要があります。

このエラーは、クラスライブラリでサービスを呼び出し、別のプロジェクトからクラスライブラリを呼び出す場合に発生する可能性があります。

この問題を作成/修正するにはいくつかの方法があるようです。私にとって、使用しているCRM製品はネイティブコードで記述されており、.NET dllを呼び出すことができますが、メインアプリケーションの上/上にある必要がある構成情報にぶつかります。私にとって、CRMアプリケーションは.NETではないので、結局、それをmachine.configファイル（必要な場所ではない）に配置する必要がありました。さらに、私の会社ではWebsenseを使用しているため、407 Proxy Authentication Requiredの問題のために、Service Referenceを追加することもできず、machine.congの変更が必要でした。

プロキシソリューション：

WCFサービスリファレンスを機能させるには、DLLのapp.configからメインアプリケーションの構成に情報をコピーする必要がありました（私にとってはmachine.configでした）。エンドポイント情報も同じファイルにコピーする必要がありました。私がそれをしたら、それは私のために働き始めました。

OK。私の場合は少し違いましたが、最終的にそれに対する修正を見つけました：Console.EXE-> DLL-> WS1の呼び出し-> DLL-> WS2の呼び出し

推奨どおり、Console.EXE.configにWS1とWS2の両方のサービスモデルの構成を用意しました。-問題は解決しませんでした。

しかし、WS2のプロキシを実際に作成して呼び出すDLLだけでなく、WS2のWS2のWebReferenceも追加するまで、それでも機能しませんでした。

クラスライブラリでWebサービスを参照する場合は、Windowsアプリケーションまたはコンソールアプリケーションにapp.configをコピーする必要があります

解決策：クラスライブラリのwcf構成と同じように外部プロジェクトの構成を変更します。

私のために働いた

同じ問題があった
デスクトップアプリとGlobal Weather Webサービスを使用しが発生しました

サービス参照を削除してWeb参照を追加し、問題を解決したおかげで

私の解決策は、クライアントのweb.configのエンドポイント名属性からエンドポイント名を削除することでした。これにより、プロキシが使用できるようになりました

ChannelFactory<TService> _channelFactory = new ChannelFactory<TService>("");

一日中運動するだけでした。また、最初のエラーが表示されたときは間違っていましたが、この修正が適用されると、契約名は間違っていました。契約名の文字列の人々をダブルチェックしてからトリプルチェックします!! attrib：Ian

もう1つ検索対象を追加できます。（トム・ハイの答えはすでにそれを暗示していますが、私は明確にしたいです）

私のweb.configファイルは次のように定義されていました：

<protocolMapping>
    <add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>

すでに1つの参照にbasicHttpsBindingを使用していましたが、basicHttpBinding（sなし）を必要とする新しい参照を追加しました。私がしなければならなかったのはprotocolMapping、次のようにそれを自分に追加することだけでした。

<protocolMapping>
    <add binding="basicHttpBinding" scheme="http" />
    <add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>

LRが正しく指摘し、これは右の場所で定義する必要があります。私にとって、それは私の単体テストプロジェクトのapp.configとメインサービスプロジェクトのweb.configの1つを意味しました。

グローバルスコープ演算子なしで構成ファイル要素のコントラクトを参照しているときに、このエラーが発生しました。

すなわち

<endpoint contract="global::MyNamepsace.IMyContract" .../>

動作しますが

<endpoint contract="MyNamepsace.IMyContract" .../>

「コントラクトを参照するデフォルトのエンドポイント要素が見つかりませんでした」エラーが発生します。

MyNamepsace.IMyContractを含むアセンブリは、メインアプリケーションとは別のアセンブリにあるため、グローバルスコープの解決を使用する必要性が説明される場合があります。

サービス参照を追加するとき

入力する名前空間に注意してください。

それをインターフェースの名前に追加する必要があります。

<client>
  <endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
            binding="basicHttpBinding" 
            contract="MyNamespace.IMySOAPWebService" />
</client>

同じエラーが発生し、多くのことを試みましたが、機能しませんでした。私の「契約」がすべてのプロジェクトで同じではないことに気付き、ソリューション内のすべてのプロジェクトで同じになるように契約を変更しました。これはプロジェクトAです

<client>
    <endpoint address="https://xxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference.IIntegrationService" name="basic" />
</client>

プロジェクトB：

<client>
    <endpoint address="xxxxxxxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference1.IIntegrationService" name="basic" />
</client>

最後に私は両方のために変更しました：

<client>
    <endpoint address="https://xxxxxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="MyServiceReferrence.IIntegrationService" name="basic" />
</client>

私は同じ問題を抱えていましたが、ホストアプリケーションとそのエンドポイントを使用するdllが同じサービス参照名を持っている場合にのみ解決されました。