Where does system.serviceModel go in web.config?

The system.serviceModel section goes as a direct child of the root element, at the same level as and . It must not be nested inside any other section. The typical order is: , , , , , , though only strictly requires being first.

What is the difference between basicHttpBinding and wsHttpBinding in WCF?

basicHttpBinding provides SOAP 1.1 compatibility and is designed for interoperability with older ASMX web services and non-.NET clients. It does not include security by default. wsHttpBinding uses SOAP 1.2 with WS-* standards including WS-Security, WS-ReliableMessaging, and WS-AtomicTransaction. Use basicHttpBinding for maximum compatibility and wsHttpBinding when you need advanced security and reliability features between WCF clients and services.

Do I still need system.serviceModel in .NET Core or .NET 5+?

No. WCF server-side hosting is not supported in .NET Core or .NET 5+. Microsoft recommends using gRPC or ASP.NET Core Web APIs as replacements. For WCF client consumption in .NET Core, you can use the System.ServiceModel NuGet packages with programmatic configuration instead of XML config files. The CoreWCF community project also provides server-side WCF support for .NET Core if migration from legacy WCF services is needed.

Where does the system.serviceModel section go in web.config?

Note: This article was originally published in 2011. WCF (Windows Communication Foundation) is a .NET Framework technology. Modern .NET applications should consider gRPC or ASP.NET Core Web APIs. Check the current documentation for the latest guidance.

When building WCF (Windows Communication Foundation) services in ASP.NET, the system.serviceModel configuration section is where you define service endpoints, bindings, and behaviors. This guide explains the correct placement within web.config, provides detailed configuration examples, and covers troubleshooting common WCF configuration issues.

Introduction

Windows Communication Foundation (WCF) is a framework for building service-oriented applications in .NET. All WCF service configuration — endpoints, bindings, behaviors, and diagnostics — lives in the <system.serviceModel> section of the application’s configuration file. For web-hosted WCF services, this means web.config. Placing this section in the wrong location is a common source of configuration errors.

Correct Placement in web.config

The <system.serviceModel> section belongs as a direct child of the root <configuration> element, at the same level as <system.web>:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration>

  <connectionStrings>
    <!-- Database connections -->
  </connectionStrings>

  <system.web>
    <compilation debug="true" targetFramework="4.8" />
  </system.web>

  <!-- system.serviceModel goes here, as a sibling of system.web -->
  <system.serviceModel>
    <!-- WCF configuration -->
  </system.serviceModel>

  <system.webServer>
    <!-- IIS configuration -->
  </system.webServer>

</configuration>

Key Rules

<system.serviceModel> is a direct child of <configuration>.
It must not be nested inside <system.web>, <system.webServer>, or any other section.
Only one <system.serviceModel> section is allowed per configuration file.
If <configSections> is present, it must appear first, but <system.serviceModel> can appear in any order relative to other sibling sections.

Complete system.serviceModel Configuration

Here is a fully annotated example showing the major subsections:

<system.serviceModel>

  <!-- Service definitions -->
  <services>
    <service name="MyApp.Services.OrderService"
             behaviorConfiguration="OrderServiceBehavior">
      <!-- Primary endpoint -->
      <endpoint address=""
                binding="basicHttpBinding"
                bindingConfiguration="SecureBasicHttp"
                contract="MyApp.Contracts.IOrderService" />
      <!-- Metadata exchange endpoint -->
      <endpoint address="mex"
                binding="mexHttpBinding"
                contract="IMetadataExchange" />
    </service>
  </services>

  <!-- Binding configurations -->
  <bindings>
    <basicHttpBinding>
      <binding name="SecureBasicHttp"
               maxBufferSize="2147483647"
               maxReceivedMessageSize="2147483647">
        <security mode="Transport">
          <transport clientCredentialType="None" />
        </security>
      </binding>
    </basicHttpBinding>
  </bindings>

  <!-- Service behaviors -->
  <behaviors>
    <serviceBehaviors>
      <behavior name="OrderServiceBehavior">
        <serviceMetadata httpGetEnabled="true"
                         httpsGetEnabled="true" />
        <serviceDebug includeExceptionDetailInFaults="false" />
        <serviceThrottling maxConcurrentCalls="100"
                           maxConcurrentInstances="100"
                           maxConcurrentSessions="100" />
      </behavior>
    </serviceBehaviors>
    <endpointBehaviors>
      <behavior name="WebBehavior">
        <webHttp />
      </behavior>
    </endpointBehaviors>
  </behaviors>

</system.serviceModel>

Understanding the Key Subsections

Services

The <services> section defines each WCF service by its fully qualified .NET class name and maps it to one or more endpoints:

<services>
  <service name="Namespace.ClassName"
           behaviorConfiguration="BehaviorName">
    <endpoint address="relative/address"
              binding="bindingType"
              contract="Namespace.IContractName" />
  </service>
</services>

name — The full type name of the service implementation class.
behaviorConfiguration — References a named behavior defined in the <behaviors> section.
endpoint — Defines how clients connect (address, binding, contract — the “ABCs” of WCF).

Bindings

Bindings define the communication protocol, encoding, and security settings:

Binding	Use Case
`basicHttpBinding`	SOAP 1.1, maximum interoperability with legacy systems
`wsHttpBinding`	SOAP 1.2, WS-Security, reliable messaging
`netTcpBinding`	High-performance .NET-to-.NET communication
`webHttpBinding`	REST-style services (JSON/XML over HTTP)
`netNamedPipeBinding`	Same-machine inter-process communication

Behaviors

Behaviors modify the runtime behavior of services and endpoints:

<behaviors>
  <serviceBehaviors>
    <behavior name="MyBehavior">
      <!-- Enable WSDL metadata publishing -->
      <serviceMetadata httpGetEnabled="true" />
      <!-- Control error detail exposure -->
      <serviceDebug includeExceptionDetailInFaults="true" />
    </behavior>
  </serviceBehaviors>
</behaviors>

Important: Set includeExceptionDetailInFaults to false in production to avoid leaking internal exception details to clients.

Client-Side Configuration

When consuming a WCF service, the client application also uses <system.serviceModel> in its app.config or web.config:

<system.serviceModel>
  <client>
    <endpoint address="https://server.example.com/OrderService.svc"
              binding="basicHttpBinding"
              bindingConfiguration="SecureBasicHttp"
              contract="OrderServiceReference.IOrderService"
              name="OrderServiceEndpoint" />
  </client>

  <bindings>
    <basicHttpBinding>
      <binding name="SecureBasicHttp"
               maxReceivedMessageSize="2147483647">
        <security mode="Transport" />
      </binding>
    </basicHttpBinding>
  </bindings>
</system.serviceModel>

Configuring for REST Services (WebHttpBinding)

To expose a WCF service as a REST API:

<system.serviceModel>
  <services>
    <service name="MyApp.Services.ProductService">
      <endpoint address=""
                binding="webHttpBinding"
                contract="MyApp.Contracts.IProductService"
                behaviorConfiguration="RestBehavior" />
    </service>
  </services>

  <behaviors>
    <endpointBehaviors>
      <behavior name="RestBehavior">
        <webHttp defaultOutgoingResponseFormat="Json"
                 helpEnabled="true" />
      </behavior>
    </endpointBehaviors>
    <serviceBehaviors>
      <behavior>
        <serviceMetadata httpGetEnabled="true" />
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

Enabling WCF Diagnostics

Add tracing to diagnose configuration and runtime issues:

<system.serviceModel>
  <!-- ... service config ... -->
  <diagnostics>
    <messageLogging logEntireMessage="true"
                    logMalformedMessages="true"
                    logMessagesAtServiceLevel="true"
                    logMessagesAtTransportLevel="true"
                    maxMessagesToLog="500" />
  </diagnostics>
</system.serviceModel>

<system.diagnostics>
  <sources>
    <source name="System.ServiceModel"
            switchValue="Warning, ActivityTracing">
      <listeners>
        <add name="traceListener"
             type="System.Diagnostics.XmlWriterTraceListener"
             initializeData="c:\logs\WCFTrace.svclog" />
      </listeners>
    </source>
  </sources>
</system.diagnostics>

Open the generated .svclog file with the WCF Service Trace Viewer (SvcTraceViewer.exe) for visual analysis.

Troubleshooting Common Issues

“Configuration section ‘system.serviceModel’ cannot be read” — The section is misplaced (likely nested inside another element) or the XML is malformed. Verify it is a direct child of <configuration>.
“Could not find a base address that matches scheme https” — The binding expects HTTPS but the service is hosted on HTTP. Either change the binding security mode or configure an HTTPS endpoint in IIS.
“The maximum message size quota for incoming messages has been exceeded” — Increase maxReceivedMessageSize and maxBufferSize in the binding configuration.
“There was no endpoint listening at…” — Verify the endpoint address matches the service URL. Check that the .svc file exists and the service is activated in IIS.
Metadata (WSDL) not available — Ensure <serviceMetadata httpGetEnabled="true" /> is in the service behavior and the behavior is referenced by the service definition.

Summary

The <system.serviceModel> section belongs as a direct child of the <configuration> root element in web.config, at the same level as <system.web>. It contains the core WCF configuration subsections: <services> (service definitions and endpoints), <bindings> (communication protocol settings), and <behaviors> (runtime behavior modifications). For modern .NET development, consider migrating WCF services to gRPC or ASP.NET Core Web APIs, but for existing .NET Framework applications, proper system.serviceModel configuration remains essential.