Blazor ASP.NET Core 3.1项目的WCF兼容与可空类型支持问询

让我来一步步帮你梳理这些问题的解决方案：

问题1：能否在.NET Framework中支持可空类型？（或在.NET Core中支持WCF的可行方案） #

.NET Framework 4.8对可空类型的支持 #

.NET Framework 4.8可以部分支持可空引用类型（NRT），但并非原生运行时支持，而是基于C# 8.0+编译器的编译时检查：

• 你可以在项目文件中添加 <Nullable>enable</Nullable> 开启编译时的可空检查，编译器会生成NullableAttribute等标记属性来辅助代码检查。
• 注意：运行时.NET Framework 4.8不会强制执行空引用检查，仅在编译阶段给出提示；如果项目无法识别这些属性，可能需要手动引入System.Runtime.CompilerServices相关的NuGet包。

.NET Core 3.1支持WCF的可行方案 #

.NET Core 3.1提供了官方的WCF客户端支持，完全满足调用WCF服务的需求：

• 通过NuGet安装对应绑定的包，比如System.ServiceModel.Http（HTTP绑定）、System.ServiceModel.NetTcp（TCP绑定）等。
• 注意：官方实现仅支持WCF客户端，不支持在.NET Core中托管WCF服务；如果需要托管服务，只能考虑第三方开源的WCF Core类库，或者迁移到gRPC、ASP.NET Core Web API这类现代替代方案。

问题2：若不可行，能否新增一个.NET Standard 2.0项目，将可空类型编译为可被.NET Framework加载的程序集，使.NET Core项目使用可空类型库，WCF服务使用该.NET Standard 2.0版本？ #

这个方案完全可行，是跨.NET Framework和.NET Core共享业务逻辑的经典实践：

• 新建一个.NET Standard 2.0类库，在项目文件中开启<Nullable>enable</Nullable>（需要C# 8.0+编译器，VS2019及以上版本支持）。
• 该类库编译后既可以被Blazor（.NET Core 3.1）引用，享受完整的编译时可空检查；也能被.NET Framework 4.8的WCF项目引用，虽然运行时没有原生NRT支持，但编译阶段的检查已经能帮你规避大部分空引用问题。
• 注意事项：类库中要避免使用.NET Standard 2.0不兼容的API，同时如果用到.NET Framework专属类型，要确保版本兼容。

问题3：是否有更优方案？ #

根据你的场景，推荐按优先级考虑以下方案：

优先方案：直接在.NET Core中使用WCF客户端 #

如果你的需求只是调用WCF服务，而非托管服务，直接在Blazor项目中引入官方WCF客户端包即可：

• 这样不需要维护多个类库，Blazor项目可以直接开启可空类型（.NET Core 3.1支持C# 8，项目文件添加<Nullable>enable</Nullable>），同时直接调用WCF服务。
• 只有当WCF依赖的类库包含大量.NET Framework专属逻辑时，才需要考虑共享类库的方案。

过渡方案：优化共享类库架构 #

如果必须依赖.NET Framework的WCF类库，除了问题2的方案，还可以做一些优化：

• 将可空类型相关的核心业务逻辑集中在.NET Standard 2.0类库中，同时给.NET Framework项目添加System.Nullable等兼容包，确保可空属性能被正确识别。
• 尽量把与WCF绑定的逻辑和业务逻辑分离，减少跨平台的耦合度。

长远方案：迁移WCF到现代替代方案 #

如果有条件，建议逐步将WCF服务迁移到gRPC或ASP.NET Core Web API：

• 这些方案完全基于.NET Core/.NET生态，支持完整的可空类型和现代特性，后续维护成本更低。
• 当然这个方案需要评估迁移成本，包括客户端的适配工作，适合有长期迭代计划的项目。

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