Question

When I update a Service Reference I end up with :

An endpoint configuration section for contract ‘MyService.MainServiceSoap’ could not be loaded because more than one endpoint configuration for that contract was found. Please indicate the preferred endpoint configuration section by name.

my web.config ends up like this:

endpoints:

  <endpoint address="http://localhost/main/MainService.asmx"
    binding="basicHttpBinding" bindingConfiguration="MainServiceSoap"
    contract="MyService.MainServiceSoap" name="MainServiceSoap" />
  <endpoint address="http://localhost/main/MainService.asmx"
    binding="customBinding" bindingConfiguration="MainServiceSoap12"
    contract="MyService.MainServiceSoap" name="MainServiceSoap12" />

bindings:

  <basicHttpBinding>
    <binding name="MainServiceSoap" closeTimeout="00:01:00" openTimeout="00:01:00"
      receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false"
      bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
      maxBufferSize="655360" maxBufferPoolSize="5242880" maxReceivedMessageSize="655360"
      messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
      useDefaultWebProxy="true">
      <readerQuotas maxDepth="32" maxStringContentLength="81920" maxArrayLength="163840"
        maxBytesPerRead="40960" maxNameTableCharCount="163840" />
      <security mode="None">
        <transport clientCredentialType="None" proxyCredentialType="None"
          realm="" />
        <message clientCredentialType="UserName" algorithmSuite="Default" />
      </security>
    </binding>
  </basicHttpBinding>
  <customBinding>
    <binding name="MainServiceSoap12">
      <textMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16"
        messageVersion="Soap12" writeEncoding="utf-8">
        <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
          maxBytesPerRead="4096" maxNameTableCharCount="16384" />
      </textMessageEncoding>
      <httpTransport manualAddressing="false" maxBufferPoolSize="524288"
        maxReceivedMessageSize="65536" allowCookies="false" authenticationScheme="Anonymous"
        bypassProxyOnLocal="false" decompressionEnabled="true" hostNameComparisonMode="StrongWildcard"
        keepAliveEnabled="true" maxBufferSize="65536" proxyAuthenticationScheme="Anonymous"
        realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false"
        useDefaultWebProxy="true" />
    </binding>
  </customBinding>

I manually delete customBinding and Soap12 endpoint and everything works fine. But if I update the service again (right click Update Service Reference) the added custom binding is added again causing error and the need to manually remove from config file.

Does someone knows how to fix this ? I don’t want/need a custom soap12 binding.

This is the service config file:

<?xml version="1.0"?>
<configuration>
  <system.web>
    <globalization culture="es-PY" uiCulture="es-PY"/>
    <customErrors mode="Off"/>
    <webServices>
<!-- Tried adding and/or removing protocols and conformanceWarnings -->
      <protocols>
        <add name="HttpGet"/>
        <add name="HttpPost"/>
      </protocols>
<!-- -->
      <conformanceWarnings>
        <remove name="BasicProfile1_1"/>
      </conformanceWarnings>
    </webServices>
    <compilation debug="true" targetFramework="4.0"/>
  </system.web>
  <system.serviceModel>
    <standardEndpoints>
      <webHttpEndpoint>
        <standardEndpoint name="standard" maxReceivedMessageSize="6553600" maxBufferSize="6553600" transferMode="Streamed" helpEnabled="true" automaticFormatSelectionEnabled="true">
          <readerQuotas maxStringContentLength="65536000" maxArrayLength="163840" />
        </standardEndpoint>
      </webHttpEndpoint>
    </standardEndpoints>
    <behaviors>
      <serviceBehaviors>
        <behavior>

          <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
          <!--<serviceMetadata httpGetEnabled="true"/>-->
          <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
          <serviceDebug includeExceptionDetailInFaults="true"/>

        </behavior>
      </serviceBehaviors>
    </behaviors>
<!-- Tried setting multipleSiteBindingEnalbed true and false -->
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" aspNetCompatibilityEnabled="true"/>
<!--  -->

  </system.serviceModel>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
  </system.webServer>
  <connectionStrings>
    <clear/>
    <add name="GamblingEntities" connectionString="..." providerName="System.Data.EntityClient" />
    <add name="GamblingSiteEntities" connectionString="..." providerName="System.Data.EntityClient" />
  </connectionStrings>
  <system.data>
    <DbProviderFactories>
      <clear/>
      <add name="MySQL Data Provider" invariant="MySql.Data.MySqlClient" description=".Net Framework Data Provider for MySQL" type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, &#xA;Version=6.3.6.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d"/>
    </DbProviderFactories>
  </system.data>
</configuration>

Answer 1

The new ASMX runtime in .NET 2.0 supports SOAP 1.2. At this moment SOAP 1.1 is most widely being used in the industry. In the .NET Framework both SOAP 1.1 and SOAP 1.2 are supported. This means that the Web Services created in .NET Framework 2.0 will be configured to support both SOAP 1.1 and SOAP 1.2 messages. This indirectly means that the WSDLs thus created for the Web Service will have two types of bindings, i.e., SOAP 1.1 and SOAP 1.2.

Taken from here

This is why two bindings are being generated.

<remove name="HttpSoap12"/>

I guess this i how you disable this now i can understand why you see this as a workaround.
Something may have caused this when you moved your web service to the new framework and this is why some of your older web services on 1.1 possibly don’t respond in the same way.
Try targeting 2.0 framework maybe to see what happens.