使用最新Xrm SDK调用Dynamics 365 SOAP Execute失败求助

Let's break down the issues and fix this step by step. The error stack points to a TLS handshake failure even after setting ServicePointManager.SecurityProtocol, so we need to address timing, SDK compatibility, and configuration details.

1. Fix TLS Protocol Configuration Timing & Scope #

Your current TLS setting might be applied too late, or missing newer protocols that Dynamics 365 now requires. Make sure this line runs before any network-related code (including creating ServiceConfiguration or OrganizationServiceProxy):

// Enable both TLS 1.2 and 1.3 (Dynamics 365 now supports/requires these)
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13;
// Optional: For testing only, bypass certificate validation (do NOT use in production)
ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, errors) => true;

Older versions of .NET Framework might not recognize Tls13—if you get a compile error, stick with Tls12 alone, but prioritize upgrading your .NET version (see step 3).

2. Upgrade Your Xrm SDK to the Latest Version #

Older SDK versions (pre-9.x) have limited support for TLS 1.2. Ensure you're using the latest Microsoft.CrmSdk.CoreAssemblies NuGet package (v9.0.x or newer). This fixes underlying handshake issues and aligns with Dynamics 365's current API requirements.

3. Verify .NET Framework Version & Configuration #

• If you're using .NET Framework 4.5 or earlier, it doesn't support TLS 1.2 by default. Upgrade to .NET Framework 4.6.2 or newer.
• For .NET Framework 4.6+, you can enforce TLS settings via your app.config/web.config to avoid code-level issues:

<configuration>
  <system.net>
    <settings>
      <servicePointManager securityProtocol="Tls12,Tls13" />
    </settings>
  </system.net>
</configuration>

4. Simplify the Organization Service Proxy Initialization #

Your current code uses ServiceConfigurationFactory, which triggers WSDL retrieval early—this is where the failure is happening. Try directly initializing OrganizationServiceProxy to bypass some metadata retrieval overhead:

// TLS settings go FIRST
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13;

var serviceUri = new Uri("soap-url-from-365-developer-resources");
var credentials = new ClientCredentials();
credentials.UserName.UserName = "username";
credentials.UserName.Password = "password";

// Use direct proxy initialization
using (var proxy = new OrganizationServiceProxy(serviceUri, null, credentials, null))
{
    proxy.EnableProxyTypes();
    
    var request = new RetrieveAllEntitiesRequest()
    {
        EntityFilters = EntityFilters.Attributes,
        RetrieveAsIfPublished = true
    };
    
    try
    {
        var response = (RetrieveAllEntitiesResponse)proxy.Execute(request);
        var entities = response.EntityMetadata
            .Where(x => x.DisplayName.UserLocalizedLabel != null && !string.IsNullOrWhiteSpace(x.DisplayName.UserLocalizedLabel.Label))
            .ToList();
        // Process your entities here
    }
    catch (Exception ex)
    {
        // Print full exception stack for deeper debugging
        Console.WriteLine("GetAllEntities Error:\n{0}", ex.ToString());
    }
}

5. Additional Checks #

• Validate the SOAP Endpoint: Confirm the URL from Dynamics 365 Developer Resources is correct—sometimes environments get migrated, and endpoints change.
• Check User Permissions: Log into the Dynamics 365 web UI with the same username/password to ensure the account still has access to entity metadata (e.g., System Customizer or System Administrator roles).
• Firewall/Proxy: If your network uses a proxy, ensure it allows outbound traffic to the Dynamics 365 endpoint over TLS 1.2/1.3.

内容的提问来源于stack exchange，提问作者Srivathsa Harish Venkataramana