none
Runtime: Could not find default endpoint element that references contract RRS feed

  • Question

  • I am ultra frustrated with this bug and have scoured the internet always to find the same thing, namely that WCF requires the namespace and interface, blah, blah, blah. The other nice statement is that one has to define the endpoint in the client, because App.Config in the service does not get placed in the client, which is not exactly true, as the "Add Service Reference" does a pretty good job of updating the App.Config.

    Here is the system block diagram:

    • WinForm application
    • WCF Service Library
    • Windows Service Application
    • A simple WinForm test application

    The Windows Service Application starts up the WCF Service Library running on the local machine. The WinForm application calls the WCF service.

    The funny thing is that my simple WinForm test application works flawlessly, release or debug, whereas the main application throws an exception outside of the Visual Studio 2017 environment. The funny thing is that the code is the same, just one works and the other does not.

    Service Library Interface

    namespace MyServiceLibrary
    {
    	[ServiceContract]
    	public interface IMyService
    	{
    		[WebInvoke(Method = "GET", RequestFormat = WebMessageFormat.Xml, ResponseFormat = WebMessageFormat.Xml, UriTemplate = "/GetVersionInfo")]
    		[OperationContract]
    		string GetVersionInfo();
    	}
    }


    Service Library App.Config

    <configuration>
    	<system.web>
    		<compilation debug="true" />
    	</system.web>
    	<system.serviceModel>
    		<services>
    			<service behaviorConfiguration="MyServiceBehavior" name="MyServiceLibrary.MyService">
    				<endpoint
    					name="MyServiceLibrary_IMyService"
    					address="http://localhost:8733/MyService"
    					binding="basicHttpBinding"
    					bindingConfiguration="MyEndpointBinding"
    					contract="MyServiceLibrary.IMyService"
    				/>
    				<endpoint
    					address="mex"
    					binding="mexHttpBinding"
    					name="mex"
    					contract="IMetadataExchange" />
    				<!--
    				<host>
    					<baseAddresses>
    						<add baseAddress="http://localhost:8733/MyService/" />
    					</baseAddresses>
    				</host>
    				-->
    			</service>
    		</services>
    		<behaviors>
    			<serviceBehaviors>
    				<behavior name="MyServiceBehavior">
    					<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
    					<serviceDebug includeExceptionDetailInFaults="true" />
    					<dataContractSerializer maxItemsInObjectGraph="2147483647"/>
    				</behavior>
    			</serviceBehaviors>
    		</behaviors>
    		<bindings>
    			<basicHttpBinding>
    				<binding name="MyEndpointBinding"
    					sendTimeout="00:01:00"
    					maxReceivedMessageSize="2147483647"
    					transferMode="Streamed"
    					messageEncoding="Mtom">
    					<security mode="None">
    						<transport clientCredentialType="None" />
    					</security>
    				</binding>
    			</basicHttpBinding>
    			<customBinding>
    				<binding name="MyEndpointBindingCustom">
    					<textMessageEncoding messageVersion="Soap12WSAddressing10" />
    					<httpTransport transferMode="Streamed" maxReceivedMessageSize="67108864"/>
    				</binding>
    			</customBinding>
    		</bindings>
    		<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
    	</system.serviceModel>
    </configuration>


    Windows Service Application App.Config

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
    	<startup>
    		<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" />
    	</startup>
    	<system.serviceModel>
    		<services>
    			<service behaviorConfiguration="MyServiceServiceBehavior" name="MyServiceLibrary.MyService">
    				<endpoint
    					name="MyServiceLibrary_IMyService"
    					address="http://localhost:8733/MyService"
    					binding="basicHttpBinding"
    					bindingConfiguration="MyServiceEndpointBinding"
    					contract="MyServiceLibrary.IMyService"
    				/>
    				<endpoint
    					address="mex"
    					binding="mexHttpBinding"
    					name="mex"
    					contract="IMetadataExchange"
    				/>
    				<host>
    					<baseAddresses>
    						<add baseAddress="http://localhost:8733/MyService/" />
    					</baseAddresses>
    				</host>
    			</service>
    		</services>
    		<behaviors>
    			<serviceBehaviors>
    				<behavior name="MyServiceServiceBehavior">
    					<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
    					<serviceDebug includeExceptionDetailInFaults="true" />
    					<dataContractSerializer maxItemsInObjectGraph="2147483647"/>
    				</behavior>
    			</serviceBehaviors>
    		</behaviors>
    		<bindings>
    			<basicHttpBinding>
    				<binding name="MyServiceEndpointBinding"
    					sendTimeout="00:01:00">
    				</binding>
    			</basicHttpBinding>
    		</bindings>
    		<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
    	</system.serviceModel>
    </configuration>


    Windows Service OnStart() Call:

    		protected override void OnStart(string[] args)
    		{
    			// Start: My Service Library
    			Uri baseAddress = new Uri("http://localhost:8733/MyService");
    			serviceHost = new ServiceHost(typeof(MyService), baseAddress);
    			ServiceMetadataBehavior serviceBehavior = new ServiceMetadataBehavior()
    			{
    				HttpGetEnabled = true,
    			};
    			serviceHost.Description.Behaviors.Add(serviceBehavior);
    			BasicHttpBinding serviceBinding = new BasicHttpBinding();
    			//serviceBinding.Security.Mode = SecurityMode.None;
    			serviceBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.None;
    			serviceHost.AddServiceEndpoint(typeof(IMyService), serviceBinding, baseAddress);
    			serviceHost.AddServiceEndpoint(typeof(IMetadataExchange), MetadataExchangeBindings.CreateMexHttpBinding(), "mex");
    			serviceHost.Open();
    		}

    The reason for duplicating the App.Config stuff in the OnStart() event is that otherwise Windows kept throwing mega thunderous hissy fits and refused to start the service. When I code the solution as shown above, the service started.

    WinForm Application App.Config

      <system.serviceModel>
        <bindings>
          <basicHttpBinding>
            <binding name="BasicHttpBinding_IMyService" />
          </basicHttpBinding>
        </bindings>
        <client>
    	<endpoint
    		name="BasicHttpBinding_IMyService"
    		address="http://localhost:8733/MyService"
    		binding="basicHttpBinding"
    		bindingConfiguration="BasicHttpBinding_IMyService"
    		contract="MyServiceLibrary.IMyService"
    	/>
        </client>
      </system.serviceModel>

    WinForm Form Timer Code Calling Service, which fails

    		private void TimerStatus_Tick(object sender, EventArgs e)
    {
    MyServiceLibrary.MyServiceClient clientService = null;
    try
    {
    clientService = new MyServiceLibrary.MyServiceClient();
    if (null != clientService)
    {
    String serviceVersionInfo = clientService.GetVersionInfo();
    this.UpdateNoteService(serviceVersionInfo);
    }
    }

    catch (Exception)
    {
    }

    finally
    {
    // Always close the client.
    clientService?.Close();
    }
    }

    As mentioned in the title, the application at run-time throws this error. Note, WCF throws the error on the new call.

    Runtime Error:

    Could not find default endpoint element that references contract 'MyServiceLibrary.IMyService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.

    Parsing the error message, "ServiceModel client configuration section," means the "<configuration> | <system.serviceModel> | <client>" section, in particular the <endpoint> subsection in the WinForm client application App.Config file. It appears that WinForms cannot see the "MyServiceLibrary.IMyService" endpoint, even though it is there. This problem would appear to be similar to my Windows Service Application in that the information is there, just not visible for whatever reason at run-time. I would not mind knowing at run-time, displayed out to a text box via a button or something, what the WinForm application thinks the contents of that section are.

    The namespace and interface match and exist everywhere. The service runs nicely, so what gives?

    UPDATE Wednesday August 15, 2018

    Progress. I kept reading last night and this morning the full text of the error message and thinking back to my work around in the Windows Service and the phrase "this might be because no configuration file was found in your application," so I did some research and found this SO question about reading the <AppSettings>, so I tried the answer given by Rama (non-accepted answer), which gives FULL code to test. What I found was that indeed my test application reports back the values of the <AppSettings>, while my real application and my Windows Service both do NOT (no values returned). That explains the issues that I saw on both applications and why I was forced to do that work around method in the OnStart() event.

    That means that the error message was indeed right. There is no endpoint, because there is no configuration file found for my application, even though it is right there.

    Now I have to research why the non-recognition of the App.config file.


    Tuesday, August 14, 2018 9:35 PM

Answers

  • With what should be great fanfare and heaps of praise from the universe for solving my own problem with nobody responding to my posts on SO or here on MSDN, I figured out the problems that I have been seeing. Okay, one person voted down my question.

    This SO question gets to the heart of the problem. Visual Studio on WinForm applications, exactly like on ASP.Net web applications, do NOT embed the configuration file (App.Config). The developer must distribute the .config file along with the executable. Moreover, the compiler renames App.Config to "MyWhatever.dll.config" or "MyWhatever1.exe.config". The config files are there in the build folder. they are not just there for taking up space and to be ignored, what I thought, but to actually distribute.

    Now I understand why the application worked from Visual Studio and my test application worked. In both cases, I was using the EXE from the built project rather than the installed location. Both had the .config file.

    I now cannot start the service, :-), as there are duplicate entries for the config stuff. Finally.

    Wednesday, August 15, 2018 3:21 PM

All replies

  • With what should be great fanfare and heaps of praise from the universe for solving my own problem with nobody responding to my posts on SO or here on MSDN, I figured out the problems that I have been seeing. Okay, one person voted down my question.

    This SO question gets to the heart of the problem. Visual Studio on WinForm applications, exactly like on ASP.Net web applications, do NOT embed the configuration file (App.Config). The developer must distribute the .config file along with the executable. Moreover, the compiler renames App.Config to "MyWhatever.dll.config" or "MyWhatever1.exe.config". The config files are there in the build folder. they are not just there for taking up space and to be ignored, what I thought, but to actually distribute.

    Now I understand why the application worked from Visual Studio and my test application worked. In both cases, I was using the EXE from the built project rather than the installed location. Both had the .config file.

    I now cannot start the service, :-), as there are duplicate entries for the config stuff. Finally.

    Wednesday, August 15, 2018 3:21 PM
  • I am finding a similar issue.

    When using SSDT (Visual Studio SQL Server Data Tools) and testing scripts, the configuration from the file app.config seems to be not not availiable.

    I have not been able to figure out why.

    I get the feeling that it is somewhat related.

    Wednesday, November 20, 2019 5:26 PM