升级.NET Framework 3.5至4.6.2后WCF服务部署异常求助

这种首次访问正常、后续卡住必须重启IIS才能再用一次的情况，我之前处理过类似案例，大概率是服务实例管理或资源未正确释放，或者是.NET版本升级后的配置兼容问题。下面给你一步步排查和解决的思路：

1. 检查服务的实例上下文模式 #

如果你的服务使用了InstanceContextMode.Single（单实例模式），所有请求会共享同一个服务实例，一旦某个请求在处理时卡住（比如资源未释放、死锁），后续请求都会排队等待，导致页面持续加载。

建议改成PerCall模式（每次请求创建新实例），这是无状态服务的最佳实践，能避免资源竞争问题：

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
public class YourTargetService : IYourTargetService
{
    // 你的服务实现代码
}

如果业务需要会话，可以用PerSession模式，但也要确保会话结束时资源能正确释放。

2. 开启WCF跟踪日志排查具体错误 #

光看现象很难定位问题，开启WCF跟踪能帮你看到第二次请求时到底发生了什么（比如线程阻塞、异常未捕获）。在服务的web.config里添加以下配置：

<system.diagnostics>
    <sources>
        <source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
            <listeners>
                <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="D:\WcfLogs\ServiceTrace.svclog" />
            </listeners>
        </source>
    </sources>
</system.diagnostics>

记得提前创建D:\WcfLogs文件夹并赋予IIS应用池读写权限。触发问题后，用Windows自带的SvcTraceViewer.exe（一般在C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools目录下）打开日志文件，就能看到请求的详细流程和错误信息。

3. 检查IIS应用程序池配置 #

• 确认应用程序池的**.NET CLR版本**设置为v4.0（.NET 4.6.2基于4.0 CLR运行，选v2.0会有兼容性问题）；
• 查看事件查看器的应用程序日志，看IIS或WCF有没有抛出未捕获的异常（比如数据库连接超时、权限不足）；
• 检查应用程序池的进程模型设置，比如是否开启了闲置超时？如果超时时间过短，服务可能被回收，但你的情况是重启才好一次，这个可能性较低，但可以暂时关闭闲置超时测试。

4. 确保服务实现中的资源正确释放 #

检查服务代码里的数据库连接、文件流、网络请求等资源，必须用using块或者手动释放，避免资源泄漏：

// 正确的数据库连接释放方式
using (var sqlConn = new SqlConnection(YourConnectionString))
{
    sqlConn.Open();
    // 执行数据库操作
}

如果资源没有被正确释放，首次请求占用后，后续请求无法获取资源就会阻塞，单实例模式下这个问题会被放大。

5. 验证服务器上.NET 4.6.2的安装完整性 #

有时候服务器上的.NET Framework安装不完整或损坏也会导致奇怪的问题。可以通过以下命令验证：
打开命令提示符（管理员权限），运行：

reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release

如果返回的Release值是394806，说明.NET 4.6.2安装正确；如果不是，建议重新下载安装.NET 4.6.2安装包。

先从实例模式和资源释放这两点入手测试，这是最常见的原因，如果还没解决，再用跟踪日志找具体错误。

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