分析现有 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。

目录
相关文章
|
1月前
|
开发框架 .NET 开发者
简化 ASP.NET Core 依赖注入(DI)注册-Scrutor
Scrutor 是一个简化 ASP.NET Core 应用程序中依赖注入(DI)注册过程的开源库,支持自动扫描和注册服务。通过简单的配置,开发者可以轻松地从指定程序集中筛选、注册服务,并设置其生命周期,同时支持服务装饰等高级功能。适用于大型项目,提高代码的可维护性和简洁性。仓库地址:<https://github.com/khellang/Scrutor>
48 5
|
2月前
|
开发框架 .NET C#
在 ASP.NET Core 中创建 gRPC 客户端和服务器
本文介绍了如何使用 gRPC 框架搭建一个简单的“Hello World”示例。首先创建了一个名为 GrpcDemo 的解决方案,其中包含一个 gRPC 服务端项目 GrpcServer 和一个客户端项目 GrpcClient。服务端通过定义 `greeter.proto` 文件中的服务和消息类型,实现了一个简单的问候服务 `GreeterService`。客户端则通过 gRPC 客户端库连接到服务端并调用其 `SayHello` 方法,展示了 gRPC 在 C# 中的基本使用方法。
51 5
在 ASP.NET Core 中创建 gRPC 客户端和服务器
|
1月前
|
开发框架 缓存 .NET
GraphQL 与 ASP.NET Core 集成:从入门到精通
本文详细介绍了如何在ASP.NET Core中集成GraphQL,包括安装必要的NuGet包、创建GraphQL Schema、配置GraphQL服务等步骤。同时,文章还探讨了常见问题及其解决方法,如处理复杂查询、错误处理、性能优化和实现认证授权等,旨在帮助开发者构建灵活且高效的API。
34 3
|
18天前
|
开发框架 算法 中间件
ASP.NET Core 中的速率限制中间件
在ASP.NET Core中,速率限制中间件用于控制客户端请求速率,防止服务器过载并提高安全性。通过`AddRateLimiter`注册服务,并配置不同策略如固定窗口、滑动窗口、令牌桶和并发限制。这些策略可在全局、控制器或动作级别应用,支持自定义响应处理。使用中间件`UseRateLimiter`启用限流功能,并可通过属性禁用特定控制器或动作的限流。这有助于有效保护API免受滥用和过载。 欢迎关注我的公众号:Net分享 (239字符)
37 0
|
2月前
|
前端开发 C# Windows
在WPF程序中实现PropertyGrid功能
【11月更文挑战第15天】PropertyGrid 是一个用户界面组件,用于直观地查看和编辑对象属性。在 WPF 中可通过组合 Expander 和 DataGrid 实现基本功能,或使用第三方库 PropertyTools 获得更强大特性,包括属性验证和类型特定编辑器。
|
2月前
|
开发框架 监控 .NET
【Azure App Service】部署在App Service上的.NET应用内存消耗不能超过2GB的情况分析
x64 dotnet runtime is not installed on the app service by default. Since we had the app service running in x64, it was proxying the request to a 32 bit dotnet process which was throwing an OutOfMemoryException with requests >100MB. It worked on the IaaS servers because we had the x64 runtime install
|
2月前
Visual Studio 快速分析 .NET Dump 文件
【11月更文挑战第10天】.NET Dump 文件是在 .NET 应用程序崩溃或出现问题时生成的,记录了应用程序的状态,包括内存对象、线程栈和模块信息。通过分析这些文件,开发人员可以定位和解决内存泄漏、死锁等问题。在 Visual Studio 中,可以通过调试工具、内存分析工具和符号加载等功能来详细分析 Dump 文件。此外,还可以使用第三方工具如 WinDbg 进行更深入的分析。
|
3月前
|
存储 数据挖掘 API
购物平台数据抓取实战指南:从API到深度分析
本指南介绍如何通过API接口抓取淘宝、京东、拼多多等电商平台的数据,涵盖API选择、注册配置、数据抓取与处理、深度分析等内容,帮助企业和开发者挖掘数据价值,支持市场分析和决策制定。
|
3月前
|
安全 API 数据安全/隐私保护
商品详情API接口的优势分析与应用价值
在数字化时代,商品详情API接口为商家和开发者提供了实时更新、高效集成、丰富功能、安全稳定、易于扩展及提升用户体验的解决方案,助力提高运营效率、降低成本并增强市场竞争力。
|
3月前
|
开发框架 缓存 监控
NET Framework 到 .NET 5/6 的迁移是重大的升级
本文详细介绍了从 .NET Framework 4.8 迁移到 .NET 5/6 的过程,通过具体案例分析了迁移策略与最佳实践,包括技术栈评估、代码迁移、依赖项更新及数据库访问层的调整,强调了分阶段迁移、保持代码可维护性及性能监控的重要性。
70 3