客户经常问的一个问题是，如何在 .NET Core 中获得 RPC 体验（就像在 .NET 远程和 Windows Communication Foundation 中一样）。我们正在参与 gRPC (grpc.io) 项目，以确保 gRPC 能够为 .NET 开发人员提供一流支持。
在今年早些时候，我们开始了一项试验，即使用 .NET（我们称之为 Blazor）进行客户端 Web 开发。借助 Blazor，可以编写直接在浏览器中的基于 WebAssembly 的 .NET 运行时内运行的 Web UI 组件，而无需编写一行 JavaScript。使用 Razor 语法创作组件，这些组件与代码一起被编译到常规 .NET 程序集中。然后，程序集和基于 WebAssembly 的 .NET 运行时被下载到浏览器中，仅使用开放式 Web 标准就能执行它们（无需任何插件或代码转换），如图 1所示。
图 1：使用 Blazor 进行客户端 Web 开发
也可以使用 .NET Core 在服务器上运行相同组件，其中所有 UI 交互和 DOM 更新都是通过 SignalR 连接进行处理，如图 2所示。执行后，组件跟踪 DOM 所需的更新，并通过 SignalR 连接将要应用的这些更新发送到浏览器。UI 事件使用同一连接发送到服务器。此模型的优点有多个：下载大小更小、代码集中在服务器上，以及受益于在 .NET Core 上运行组件的所有功能和性能优势。
图 2：使用 SignalR 在服务器上运行 UI Web 组件
对于 .NET Core 3.0，我们将把 Blazor 组件模型集成到 ASP.NET Core 中。我们将此集成组件模型称为“Razor 组件”。Razor 组件开启了以下新时代：使用 ASP.NET Core 的可组合 UI，以及使用 .NET 的完整堆栈 Web 开发。对于 .NET Core 3.0，Razor 组件最初作为独立可路由组件，或通过 Razor Pages 和视图使用的组件在服务器上运行。不过，相同组件也可以在 WebAssembly 上进行客户端运行。在开发 .NET Core 3.0 的同时，我们还将继续着手以下工作：支持使用基于解释器的 .NET 运行时在 WebAssembly 上运行 Razor 组件，预计将在后续版本中提供。之后，我们还计划向 WebAssembly 发布对 .NET 代码的完全预编译支持，这将显著提升运行时性能。
EF Core 3.0
LINQ 是一项用户钟爱的 .NET 功能，可便于编写数据库查询，而无需离开所选的语言，同时还能利用丰富的类型信息来获取 IntelliSense 和编译时类型检查。不过，LINQ 也支持编写数量几乎不限的复杂查询，而这对于 LINQ 提供程序来说，一直都是一项巨大挑战。EF Core 部分解决了此问题，具体方法是支持选择可转换为 SQL 的查询部分，再执行内存中剩余的查询。在某些情况下，这样做是可取的，但在其他许多情况下，这可能会导致非常低效的查询直到应用程序投入生产才被发现。
在 EF Core 3.0 中，我们计划深入更改 LINQ 实现工作原理和测试方式，旨在提高它的可靠性（例如，避免破坏修补程序版本中的查询）；让它能够将更多表达式正确转换为 SQL；在更多情况下生成高效查询；以及防止直到投入生产才被检测到的非常低效查询出现。
我们一直在致力于开发适用于 EF Core 的 Cosmos DB 提供程序，以便开发人员能够熟悉 EF 编程模型，从而轻松地将 Azure Cosmos DB 定目标为应用程序数据库。目标是利用 Cosmos DB 的一些优势，如全局分发、“始终开启”可用性、弹性可伸缩性和低延迟，甚至包括 .NET 开发人员可以更轻松地访问它。此提供程序将针对 Cosmos DB 中的 SQL API 启用大部分 EF Core 功能，如自动更改跟踪、LINQ 和值转换。
我们计划在 EF Core 3.0 中添加的其他功能包括，属性包实体（将数据存储在索引属性（而不是常规属性）中的实体）；能够将数据库视图反向工程为查询类型；以及与新 C# 8.0 功能集成，如 IAsyncEnumerable<T> 支持和可以为 null 的引用类型。
我们理解，对于许多使用旧版 EF 的现有应用程序来说，移植到 EF Core 的工作量巨大。正因为此，我们还移植了 EF 6，以便能够使用 .NET Core。
.NET Standard 2.1
如果遵循 .NET Standard，可以创建适用于所有 .NET 实现的库，不仅仅局限于 .NET Core，还包括 Xamarin 和 Unity。在 .NET Standard 1.x 中，我们只对跨各种实现已常用的 API 进行了建模。在 .NET Standard 2.0 中，我们专注于简化将现有 .NET Framework 代码移植到 .NET Core 的过程，这样不仅带来了额外的 20,000 个 API，还带来了兼容性模式（可便于从基于 .NET Standard 的库引用 .NET Framework 库，而无需重新编译它们）。对于这两版标准，几乎没有任何新组件，因为所有 API 都是现有 .NET API。