WCF服务在Visual Studio中正常运行但在LinqPad 5中调用失败的问题求助

这种情况我碰到过好多次了，LinqPad和Visual Studio的运行环境差异往往是关键，尤其是WCF认证这块。给你列几个一步步排查的方向，按顺序来试应该能找到问题：

VS默认会用你当前登录的Windows账号运行，但LinqPad有时候可能以不同权限启动（比如右键选了管理员身份），这会导致WCF的Windows认证直接失败。你可以在LinqPad里加一段代码输出当前用户：

Console.WriteLine(System.Security.Principal.WindowsIdentity.GetCurrent().Name);

把这个输出和VS里运行时的用户对比，确保两者完全一致。如果LinqPad用的是其他账号，切换回普通用户身份启动LinqPad再试。

有时候LinqPad不会自动读取你引用DLL的app.config，哪怕你把配置文件拖进去了也没用。你可以手动验证配置是否加载成功：

var config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
var clientSection = config.GetSection("system.serviceModel/client") as ClientSection;
if (clientSection?.Endpoints.Count > 0)
{
    Console.WriteLine($"加载的端点地址：{clientSection.Endpoints[0].Address}");
    Console.WriteLine($"绑定名称：{clientSection.Endpoints[0].Binding}");
}
else
{
    Console.WriteLine("未加载到WCF客户端配置");
}

如果输出的地址或绑定和VS里的不一样，说明LinqPad没读到正确配置。解决办法是：

• 打开LinqPad的查询属性（点击查询窗口右上角的齿轮图标）
• 在“附加配置”里把app.config中system.serviceModel节点的完整内容复制进去

错误信息里提到了SspiNegotiationTokenProvider，这和Windows认证的协商流程有关。LinqPad的环境可能不支持默认的协商模式，你可以强制指定用NTLM认证试试：

方式一：通过配置修改 #

把这段配置加到LinqPad的“附加配置”里：

<system.serviceModel>
  <bindings>
    <wsHttpBinding>
      <binding name="YourBindingName">
        <security mode="Message">
          <message clientCredentialType="Windows" negotiateServiceCredential="false" establishSecurityContext="false"/>
        </security>
      </binding>
    </wsHttpBinding>
  </bindings>
</system.serviceModel>

方式二：通过代码直接设置绑定 #

如果不想改配置，也可以在LinqPad的代码里手动创建绑定：

var binding = new WSHttpBinding();
binding.Security.Mode = SecurityMode.Message;
binding.Security.Message.ClientCredentialType = MessageCredentialType.Windows;
// 关闭自动协商，强制用NTLM
binding.Security.Message.NegotiateServiceCredential = false;
binding.Security.Message.EstablishSecurityContext = false;

// 用新创建的绑定实例化客户端
var client = new GenericServiceClient(binding, new EndpointAddress("http://localhost:2001/GenericService"));

LinqPad5默认可能不会自动用4.8运行，你可以看查询窗口右下角的框架版本标识，确保显示的是.NET Framework 4.8。如果不是，点击这个标识切换到4.8版本后再运行查询。

如果上面的方法都没解决，就去服务端开跟踪日志，看具体是认证哪一步出了问题。在服务端的web.config里添加这段配置：

<system.diagnostics>
  <sources>
    <source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
      <listeners>
        <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="C:\Logs\WcfServiceTrace.svclog" />
      </listeners>
    </source>
    <source name="System.ServiceModel.MessageLogging">
      <listeners>
        <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="C:\Logs\WcfMessageLog.svclog" />
      </listeners>
    </source>
  </sources>
</system.diagnostics>

然后用LinqPad发起请求，生成日志后用WCF Service Trace Viewer（VS里自带的工具）打开日志文件，里面会详细记录服务端拒绝请求的具体原因——比如账号没有权限、协议协商失败，或者是身份验证的协议不支持。

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