内容简介:今年五月的 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本文将介绍其使用方法,并介绍 A
今年五月的 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 程序
其实这个目录下只有一点点程序集,所以分析起来很快的。
▲ Whitman 的目录结构
选好后,点击 Analyze ,在 Analyzing… 提示等待之后,即可在它指定的临时目录中找到分析结果文件:
Report saved in: C:\Users\walterlv\AppData\Local\Temp\PortabilityReport.xlsx
竟然是一个 Excel 表格!
▲ Excel 表格表示的结果
可以看到,我的 Whitman 对 .NET Core 3.0 的 API 是 100% 兼容的。将来迁移的时候可以不需要修改代码。
分析更复杂的程序
我试着分析一个更庞大的 WPF 软件目录后,发现还是有一些 API 是不兼容的。
▲ 有一些 API 不兼容
▲ 有一些程序集兼容性很低
这份 Excel 表格中还包含了具体哪些 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。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 主机Redis服务迁移到现有Docker Overlay环境
- Flutter 添加到现有项目
- 现有iOS工程引入Flutter
- 为现有 iOS项目集成 Flutter
- QLoo推出用于现有服务的GraphQL接口
- 观点 | 激励循环——加密算法如何实际修复现有激励循环
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
赛博空间的奥德赛
(荷兰)约斯·德·穆尔 (Jos de Mul) / 麦永雄 / 广西师范大学出版社 / 2007-2 / 38.00元
本书揭示了数码信息时代的电子传媒与赛博空间为人类历史的发展提供的新的可能性。本书第一部分“通向未来的高速公路”,涉及无线想象、政治技术和极权主义在赛博空间的消解等题旨;第二部分“赛博空间的想象” ,讨论空间文学探索简史、电影和文化的数码化;第三部分”可能的世界” ,关涉世界观的信息化、数码复制时代的世界、数码此在等层面;第四、五部分探讨主页时代的身份、虚拟人类学、虚拟多神论、赛博空间的进化、超人文......一起来看看 《赛博空间的奥德赛》 这本书的介绍吧!