如何将WCF服务迁移至.NET Core类库？绑定替代方案咨询

我来给你拆解下这个迁移问题的可行方案——你原来用WebHttpBinding构建的RESTful WCF服务，在.NET Core里确实没有原生的服务端支持，但有几个贴合.NET Core生态的替代路径，同时也会覆盖你代码里的TCP服务部分：

一、优先转用ASP.NET Core Web API（最推荐） #

WebHttpBinding本质是WCF的REST实现，而ASP.NET Core Web API是.NET Core原生的REST服务框架，完全能替代原有功能，生态更完善、维护成本更低：

对应你原有配置的替换方式： #

1. 流式传输与大消息支持
   你原来设置的TransferMode = Streamed和MaxReceivedMessageSize = long.MaxValue，可以通过ASP.NET Core的配置实现：

   • 在Program.cs（或Startup.cs）中配置Kestrel的最大请求大小：

     WebHost.CreateDefaultBuilder(args)
            .UseKestrel(options =>
            {
                options.Limits.MaxRequestBodySize = long.MaxValue;
            })
            .UseStartup<Startup>();
     

   • 在需要处理流式请求的Controller方法上，直接读取Request.Body即可。

2. Gzip压缩与Content-Type配置
   原来的ContentEncodingBehavior可以用.NET Core原生的ResponseCompressionMiddleware替代：

   • 在Startup.cs的ConfigureServices中注册压缩服务：

     services.AddResponseCompression(options =>
     {
         options.Providers.Add<GzipCompressionProvider>();
         // 添加application/bson到压缩支持的MIME类型
         options.MimeTypes = ResponseCompressionDefaults.MimeTypes.Concat(new[] { "application/bson" });
     });
     

   • 在Configure中间件管道中启用压缩：

     app.UseResponseCompression();
     

   • 响应的Content-Type可以直接在Controller方法中设置：Response.ContentType = "application/bson";

3. 超时设置
   原来的各类Timeout可以通过Kestrel配置对应项，比如：

   options.Limits.KeepAliveTimeout = TimeSpan.FromHours(6);
   options.Limits.RequestHeadersTimeout = TimeSpan.FromSeconds(10);
   

示例Controller代码（对应原IHttpWebService）： #

[ApiController]
[Route("")] // 匹配你原来的服务根地址
public class HttpWebServiceController : ControllerBase
{
    private readonly IHttpWebService _service;
    private readonly ILogger<HttpWebServiceController> _logger;

    public HttpWebServiceController(IHttpWebService service, ILogger<HttpWebServiceController> logger)
    {
        _service = service;
        _logger = logger;
    }

    // 对应原服务契约中的方法，根据实际HTTP动词调整
    [HttpPost]
    [RequestSizeLimit(long.MaxValue)] // 单独设置该接口的最大请求大小
    public async Task<IActionResult> ProcessRequest()
    {
        // 读取Bson格式的请求流
        using var requestStream = Request.Body;
        var requestModel = BsonSerializer.Deserialize<YourRequestType>(requestStream);

        // 调用原有业务逻辑
        var responseModel = await _service.YourServiceMethod(requestModel);

        // 返回Bson格式响应
        Response.ContentType = "application/bson";
        await using var responseStream = Response.Body;
        BsonSerializer.Serialize(responseStream, responseModel);

        return Ok();
    }
}

（注：需要引入MongoDB.Bson库来处理Bson序列化/反序列化）

二、针对NetTcpBinding服务的替代（.NET Core 2.1限制） #

.NET Core 2.1原生不支持NetTcpBinding的服务端，你有两个选择：

1. 升级到.NET Core 3.0+：从3.0开始，.NET Core引入了WCF服务端的NetTcp支持，可以直接沿用类似原代码的写法。
2. 改用SignalR替代：SignalR是.NET Core原生的双向通信框架，能实现类似TCP服务的实时交互，在2.1版本中完全支持，适配性更好。
3. 自定义TCP服务：基于TcpListener封装简单的TCP通信逻辑，或者使用第三方库如SuperSocket来简化开发。

三、关于SoapCore的补充 #

SoapCore主要是用来在.NET Core中实现SOAP风格的WCF服务，对于你这种REST风格的场景确实不太适配，所以更推荐上面的Web API方案，这也是.NET官方推荐的迁移路径。

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