如何在Web.config中配置多个SOAP服务？自定义包装类场景处理

Got it, let’s walk through how to set this up correctly—this is a super common scenario when wrapping legacy SOAP services, and I’ve sorted this out a bunch of times before. Here’s the step-by-step breakdown:

1. Let Visual Studio Do Its Initial Work First #

When you add each SOAP service reference in Visual Studio, it will automatically inject configuration entries into your project’s Web.config (or App.config for class libraries, but critical note: class library configs don’t get used at runtime—you’ll need to copy these settings to your main application’s Web.config eventually).

The auto-generated config will add two key sections under <system.serviceModel>:

• <bindings>: Defines communication settings (like security, timeouts, message size limits) for each service’s connection.
• <client>: Contains <endpoint> entries that map to each SOAP service’s address, binding, and contract.

2. Clean Up and Standardize the Configuration #

VS sometimes generates generic names (like BasicHttpBinding_IService1) which can get messy with multiple services. Take a minute to rename things for clarity:

• For each <endpoint> in the <client> section, set a unique, descriptive name (e.g., "CustomerSoapServiceEndpoint", "OrderSoapServiceEndpoint"). This name is what your wrapper classes will reference later.
• If multiple services use identical binding settings, you can reuse a single binding definition instead of duplicating it—just make sure each <endpoint> points to the correct binding name.

Here’s a cleaned-up example of what your <system.serviceModel> section might look like:

<system.serviceModel>
  <bindings>
    <!-- Reusable basic HTTP binding for all SOAP services -->
    <basicHttpBinding>
      <binding name="StandardSoapBinding" maxReceivedMessageSize="2097152">
        <security mode="Transport" />
      </binding>
    </basicHttpBinding>
  </bindings>
  <client>
    <!-- First SOAP Service Endpoint -->
    <endpoint 
      name="CustomerSoapServiceEndpoint"
      address="https://api.example.com/CustomerService.asmx"
      binding="basicHttpBinding"
      bindingConfiguration="StandardSoapBinding"
      contract="YourClassLibraryNamespace.ICustomerService" />
    
    <!-- Second SOAP Service Endpoint -->
    <endpoint 
      name="OrderSoapServiceEndpoint"
      address="https://api.example.com/OrderService.asmx"
      binding="basicHttpBinding"
      bindingConfiguration="StandardSoapBinding"
      contract="YourClassLibraryNamespace.IOrderService" />
  </client>
</system.serviceModel>

3. Reference the Endpoint Name in Your Wrapper Classes #

In each of your custom wrapper classes, when you instantiate the auto-generated service client, use the constructor that accepts the endpointConfigurationName parameter—this tells the client which config entry to use.

For example, in your CustomerServiceWrapper class:

public class CustomerServiceWrapper
{
    private readonly ICustomerService _serviceClient;

    public CustomerServiceWrapper()
    {
        // Use the exact endpoint name from Web.config
        _serviceClient = new CustomerServiceClient("CustomerSoapServiceEndpoint");
    }

    // Your extended methods here...
}

4. Critical Note for Class Library Wrappers #

Since your wrapper classes live in a class library project, remember that class library config files are ignored at runtime. You must copy all the <system.serviceModel> configuration from the class library’s App.config into your main application’s Web.config. This is the most common pitfall here—don’t skip this step!

5. Troubleshooting Common Issues #

• "Could not find endpoint element with name...": Double-check that the name in your wrapper’s constructor exactly matches the name attribute of the <endpoint> in Web.config. Case sensitivity matters here.
• Connection/Timeout Errors: Verify the address in the endpoint is correct, and adjust binding settings (like maxReceivedMessageSize, sendTimeout) if you’re dealing with large payloads or slow services.
• Mismatched Contracts: Ensure the contract attribute in the endpoint matches the fully qualified namespace of the auto-generated service interface (Visual Studio usually handles this, but it’s worth checking if you’ve renamed namespaces).

内容的提问来源于stack exchange，提问作者jacobsowles