分析现有 WPF / Windows Forms 程序能否顺利迁移到 .NET Core 3.0(使用 .NET Core 3.0 Desktop API Analyzer )

简介: 原文:分析现有 WPF / Windows Forms 程序能否顺利迁移到 .NET Core 3.0(使用 .NET Core 3.0 Desktop API Analyzer ) 版权声明:本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
原文: 分析现有 WPF / Windows Forms 程序能否顺利迁移到 .NET Core 3.0(使用 .NET Core 3.0 Desktop API Analyzer )

版权声明:本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。欢迎转载、使用、重新发布,但务必保留文章署名吕毅(包含链接:http://blog.csdn.net/wpwalter/),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。如有任何疑问,请与我联系(walter.lv@qq.com)。 https://blog.csdn.net/WPwalter/article/details/82859449

今年五月的 Build 大会上,微软说 .NET Core 3.0 将带来 WPF / Windows Forms 这些桌面应用的支持。当然,是通过 Windows 兼容包(Windows Compatibility Pack)实现的。为了提前检查你的程序是否能在未来跑在 .NET Core 3.0 上,微软在 2018年8月8日 推出了 .NET Core 3.0 Desktop API Analyzer,帮助你提前检查你的程序能有多容易迁移到 .NET Core 3.0

本文将介绍其使用方法,并介绍 API 的逐步迁移方法。


.NET Core 3.0 Desktop API Analyzer

你可以前往 GitHub 查看 .NET Core 3.0 Desktop API Analyzer 项目:

去 release 标签下即可下载。当然,目前仅发布一个版本,你也可以点击以下链接直接下载:

下载完后解压到任意目录即可运行。

分析一个 WPF 程序

第一个想到的,是分析目前已在商店发布的基于 .NET Framework 4.7 的 WPF 程序 标识符命名工具 - Whitman

分析 WPF 程序
▲ 分析 WPF 程序

其实这个目录下只有一点点程序集,所以分析起来很快的。

Whitman 的目录结构
▲ Whitman 的目录结构

选好后,点击 Analyze,在 Analyzing… 提示等待之后,即可在它指定的临时目录中找到分析结果文件:

Report saved in: 
C:\Users\walterlv\AppData\Local\Temp\PortabilityReport.xlsx

竟然是一个 Excel 表格!

Excel 表格表示的结果
▲ Excel 表格表示的结果

可以看到,我的 Whitman 对 .NET Core 3.0 的 API 是 100% 兼容的。将来迁移的时候可以不需要修改代码。

分析更复杂的程序

我试着分析一个更庞大的 WPF 软件目录后,发现还是有一些 API 是不兼容的。

有一些 API 不兼容
▲ 有一些 API 不兼容

有一些程序集兼容性很低
▲ 有一些程序集兼容性很低

这份 Excel 表格中还包含了具体哪些 API 是不兼容的,并为部分使用提供了建议:

查看不兼容的 API
▲ 查看不兼容的 API

所以,我们只需要查找对对应 API(第一列)的使用,然后通过其他技术手段将其替换成别的方法来写即可解决这样的兼容性问题。

着手解决兼容性问题

比如我们拿出其中一行:

Target type Target member Header for assembly name entries .NET Core Recommended changes
T:System.Runtime.Remoting.Messaging.MethodCallMessageWrapper T:System.Runtime.Remoting.Messaging.MethodCallMessageWrapper Walterlv.Placeholder Not supported Remove usage.

我们通过在 Walterlv.Placeholder(这只是个占位程序集,实际名称已隐去)中全解决方案中搜索 MethodCallMessageWrapper 可以找到此 API 的所有使用。

public override IMessage Invoke(IMessage msg)
{
    var caller = new MethodCallMessageWrapper((IMethodCallMessage) msg);
    // 省略其他代码。
}

此方法在此处上下文的目的是实现 AOP 代理,即为了实现切面编程,允许在实体类的每个方法执行之前注入一些代码。

既然此处基于 .NET Framework MethodCallMessageWrapper 的 AOP 已不可用,那么我们需要寻找到 .NET Core 中 AOP 的替代品。例如 .NET Core 官方推荐的是:

于是,我们几乎需要改造此类型,使其对 .NET Framework 中 MethodCallMessageWrapper 的使用替换成对 AspectCore-Framework 的依赖。

这是一项繁重的工作,不过还是要做的。迁移到 .NET Core 有很多好处,不是吗?

一些错误

额外的,在其他一些程序的分析中,我遇到了一些错误。通过混淆的比较,我认为此错误可能源于程序集的混淆:

Unable to analyze.
Details:
Detecting assembly references                      [Failed]

Cannot locate assembly information for System.Object. Microsoft assemblies found are:
Cannot locate assembly information for System.Object. Microsoft assemblies found are:
Cannot locate assembly information for System.Object. Microsoft assemblies found are:
Cannot locate assembly information for System.Object. Microsoft assemblies found are:
Cannot locate assembly information for System.Object. Microsoft assemblies found are:
Cannot locate assembly information for System.Object. Microsoft assemblies found are:
Cannot locate assembly information for System.Object. Microsoft assemblies found are:
Cannot locate assembly information for System.Object. Microsoft assemblies found are:

如果你想了解更多混淆相关的资料,可以阅读我的另一篇博客:.NET 中各种混淆(Obfuscation)的含义、原理、实际效果和不同级别的差异(使用 SmartAssembly)

未来的迁移

.NET Core 并不会原生提供 WPF / Windows Forms 这些桌面应用的支持,而是通过 Windows 兼容包(Windows Compatibility Pack)实现。你可以阅读微软官方博客了解:

Announcing the Windows Compatibility Pack for .NET Core - .NET Blog

迁移到 .NET Core 并不会为这些程序带来跨平台特性,只是能够充分利用到 .NET Core 带来的诸多好处而已。比如更高的性能,更方便的部署,及时的更新。当然还有 MIT 开源,我们能够和社区一起修复 Bug。

目录
相关文章
|
21天前
|
开发框架 .NET 开发者
简化 ASP.NET Core 依赖注入(DI)注册-Scrutor
Scrutor 是一个简化 ASP.NET Core 应用程序中依赖注入(DI)注册过程的开源库,支持自动扫描和注册服务。通过简单的配置,开发者可以轻松地从指定程序集中筛选、注册服务,并设置其生命周期,同时支持服务装饰等高级功能。适用于大型项目,提高代码的可维护性和简洁性。仓库地址:<https://github.com/khellang/Scrutor>
39 5
|
4天前
|
区块链 C# Windows
PasteEx:一款.NET开源的Windows快捷粘贴神器
PasteEx:一款.NET开源的Windows快捷粘贴神器
33 17
|
4天前
|
Web App开发 C# Windows
一款.NET开源的Windows资源管理器标签页工具
一款.NET开源的Windows资源管理器标签页工具
|
2月前
|
开发框架 .NET C#
在 ASP.NET Core 中创建 gRPC 客户端和服务器
本文介绍了如何使用 gRPC 框架搭建一个简单的“Hello World”示例。首先创建了一个名为 GrpcDemo 的解决方案,其中包含一个 gRPC 服务端项目 GrpcServer 和一个客户端项目 GrpcClient。服务端通过定义 `greeter.proto` 文件中的服务和消息类型,实现了一个简单的问候服务 `GreeterService`。客户端则通过 gRPC 客户端库连接到服务端并调用其 `SayHello` 方法,展示了 gRPC 在 C# 中的基本使用方法。
45 5
在 ASP.NET Core 中创建 gRPC 客户端和服务器
|
27天前
|
算法 Java 测试技术
Benchmark.NET:让 C# 测试程序性能变得既酷又简单
Benchmark.NET是一款专为 .NET 平台设计的性能基准测试框架,它可以帮助你测量代码的执行时间、内存使用情况等性能指标。它就像是你代码的 "健身教练",帮助你找到瓶颈,优化性能,让你的应用跑得更快、更稳!希望这个小教程能让你在追求高性能的路上越走越远,享受编程带来的无限乐趣!
83 13
|
21天前
|
弹性计算 开发框架 安全
基于云效 Windows 构建环境和 Nuget 制品仓库进行 .Net 应用开发
本文将基于云效 Flow 流水线 Windows 构建环境和云效 Packages Nuget 制品仓库手把手教你如何开发并部署一个 .NET 应用,从环境搭建到实战应用发布的详细教程,帮助你掌握 .NET 开发的核心技能。
|
29天前
|
开发框架 缓存 .NET
GraphQL 与 ASP.NET Core 集成:从入门到精通
本文详细介绍了如何在ASP.NET Core中集成GraphQL,包括安装必要的NuGet包、创建GraphQL Schema、配置GraphQL服务等步骤。同时,文章还探讨了常见问题及其解决方法,如处理复杂查询、错误处理、性能优化和实现认证授权等,旨在帮助开发者构建灵活且高效的API。
27 3
|
6天前
|
开发框架 算法 中间件
ASP.NET Core 中的速率限制中间件
在ASP.NET Core中,速率限制中间件用于控制客户端请求速率,防止服务器过载并提高安全性。通过`AddRateLimiter`注册服务,并配置不同策略如固定窗口、滑动窗口、令牌桶和并发限制。这些策略可在全局、控制器或动作级别应用,支持自定义响应处理。使用中间件`UseRateLimiter`启用限流功能,并可通过属性禁用特定控制器或动作的限流。这有助于有效保护API免受滥用和过载。 欢迎关注我的公众号:Net分享 (239字符)
25 0
|
3月前
|
存储 数据挖掘 API
购物平台数据抓取实战指南:从API到深度分析
本指南介绍如何通过API接口抓取淘宝、京东、拼多多等电商平台的数据,涵盖API选择、注册配置、数据抓取与处理、深度分析等内容,帮助企业和开发者挖掘数据价值,支持市场分析和决策制定。
|
5月前
|
开发框架 缓存 前端开发
循序渐进介绍基于CommunityToolkit.Mvvm 和HandyControl的WPF应用端开发(11) -- 下拉列表的数据绑定以及自定义系统字典列表控件
循序渐进介绍基于CommunityToolkit.Mvvm 和HandyControl的WPF应用端开发(11) -- 下拉列表的数据绑定以及自定义系统字典列表控件