.NET应用迁移到.NET Core--调查案例

上周已经发过三篇文章讲述做.NET 应用迁移到.NET Core的一般方法，具体内容请看：

.NET应用迁移到.NET Core（一）

.NET应用迁移到.NET Core（二）风险评估

.NET应用迁移到.NET Core（三）从商业角度看移植过程

今天给大家展示一个真实的项目的调查案例，一个轻量级的.NET 工作流引擎移植到.NET Core平台的调查案例，你也可以参照这篇案例进行迁移前的项目调查工作。

该调查问卷可以作为移植技术的一个指南，并且据此还可以提出其他一些问题。该问卷中的客户指的是一个要移植到.NET Core的内部或外部部门。

平台相关的内容

1、你当前的应用程序开发平台是什么？

该问题是关于开发待移植.NET应用程序的开发平台。这里不假设开发平台和应用程序部署的平台是相同的。这留在下一个问题中。

Windows 7 + IIS 7.5 + .NET Framework 4.5 +Redis 2.4 + SQL Server 2008 R2

2、该应用程序当前运行的平台是什么？

移植工程师需要知道待移植的应用程序当前运行的平台。

Windows 2008 R2 SP1 + IIS 7.5 + .NETFramework 4.5 + Redis 2.4 + SQL Server 2008 R2

3、除了开发平台外，该应用程序是否还在其他平台上部署过？如果部署过，它运行的平台版本是什么?

问此问题可以让你知道应用程序的可移植性，看它是否移植到其他平台上。不过有一点需要注意：即使应用程序曾移植到其他平台上，它的目标平台可能也是比较老的版本。

没有在其他平台部署过。

4、描述应用程序使用的系统信息，以及需要的驱动程序在Linux平台上是否可用。

确定Linux能够满足应用程序对平台的依赖。

系统信息：

.NET Framework 对应的Linux平台上有Mono 和 .NET Core两大平台
Redis 已经是在Linux平台上运行
Web服务器 IIS 对应Linux平台上有Jexus(Mono) 和 Apache/Nginx + Kestrel
SQL Server 在Linux平台上存在但是还是预览版，可以迁移到MySQL
Entity Framework 6.1 和 Entity Framework Core 本身就是跨平台的，支持在Linux平台上访问SQL Server
ServiceStack.Redis 也是支持Mono和.NET Core
Owin 服务器在Linux 平台上有Jexus 支持和 .NET Core的支持
ASP.NET Web API 2.2 Linux平台上有Mono 4.6 支持，也可以迁移到.NET Core
Windows服务可以迁移到Linux 的后台服务，可以Topshelf改造或者是迁移到.NET Core 控制台应用，使用Linux系统服务或者是Supervisorctl 运行
站点使用的ASP.Net MVC 在Linux上Mono 4.6 支持，或者迁移到.NET Core

应用程序相关的内容

1、请详细描述应用程序及其结构。

在这里，用户可以描述应用程序的结构，并尽可能地包括结构图。应用程序的所有组件都要描述。如果有的话，该问题也应该会让你知道应用程序运行的框架。大部分的.NET应用程序运行在产品相关的框架上，例如IIS 、windows 服务和WCF服务。也就是说，需要你处理.NET Core可能不支持的某个具体的框架。

HRCommFlow应用包括2部分：对外的API服务和 Web站点。

对外服务的API 服务使用ASP.NETWeb API ，使用Windows服务自宿主。使用的组件如下：

应用框架	组件	备注
ASP.NET Web API	System.Web.Http
	System.Web.Http.Owin
	Microsoft.Owin.Host.HttpListener
	EntityFramework	访问SQL Server
	Newtonsoft.Json	Json
	ServiceStack.Redis	访问Redis
	Tencent.OA.Framework	访问组织机构信息
	ExpressionEvaluator
	System.ServiceProcess

Web 站点使用ASP.NET MVC 4 ,使用IIS 宿主

应用框架	组件	备注
ASP.NET MVC	Microsoft.AspNet.Mvc
	Microsoft.AspNet.Razor
	EntityFramework	访问SQL Server
	Newtonsoft.Json	Json
	Tencent.OA.Framework	访问组织机构信息
	ExpressionEvaluator
	System.ServiceProcess

2、该应用程序有哪些不同组件？请给出各组件的名称和版本号。

该问题让你细分应用程序的结构，把应用程序细分成不同的组件。也就是说，可以把整个移植工作分成多个独立的任务。

组件名称	版本号	是否公开源代码
System.Web.Http	4.0.0.0	是
System.Web.Http.Owin	5.2.3.0	是
Microsoft.Owin.Host.HttpListener	3.0.0.0	是
EntityFramework	6.1.3	是
Newtonsoft.Json	6.0.8	是
ServiceStack.Redis	3.9.71.0	是
Tencent.OA.Framework	1.0.0.0	是
ExpressionEvaluator	2.0.4.0	是
System.ServiceProcess	4.0.0.0	是
Microsoft.AspNet.Mvc	4.0.30506.0	是
Microsoft.AspNet.Razor	2.0.30506.0	是

3、那些组件需要移植，那些不需要？请包含版本号。

客户需要告诉你那些需要移植，那些不需要。

组件名称	版本号	移植到Mono	移植到.NET Core
System.Web.Http	4.0.0.0	不需要	不需要
System.Web.Http.Owin	5.2.3.0	不需要	不需要
Microsoft.Owin.Host.HttpListener	3.0.0.0	不需要	不需要
EntityFramework	6.1.3	不需要	不需要
Newtonsoft.Json	6.0.8	不需要	不需要
ServiceStack.Redis	3.9.71.0	不需要	不需要
Tencent.OA.Framework	1.0.0.0	需要	需要
ExpressionEvaluator	2.0.4.0	需要	需要
System.ServiceProcess	4.0.0.0	不需要	不需要
Microsoft.AspNet.Mvc	4.0.30506.0	不需要	不需要
Microsoft.AspNet.Razor	2.0.30506.0	不需要	不需要

4、待移植的应用百分之多少是用下列编程语言编写?

Java
C#
F#
C
C++
汇编语言
Visual Basic
IronPython/IronRuby
Powershell

通过询问应用程序使用了什么语言及其所占的比重，来确定应用程序的复杂度。

100% 使用C# 语言编写

5、粗略估计一下各语言所占的代码行数。

这是对问题4的另外一种问法，从不同的角度提出问题，常常能找到互相矛盾的地方，这就需要公开讨论，从而能够把项目调查清楚。

代码数量大概是3500 行。

6、对于.NET应用程序：使用了P/Invoke来链接特有的库了吗？请描述之。

明确待移植的应用程序的复杂度。多数情况下，非100%纯.NET编写的应用程序，都需要平台相关的例程，这些例程只能用固有的语言来处理，例如C语言。请注意这些平台相关的代码，往往它需要花费较多的时间来移植。

没有

7、应用程序用了操作系统内核模块了吗？如果有，请描述之。

明确待移植的应用程序的复杂度。如果应用程序使用的操作系统内核模块和例程是不可移植的，就需要花费较多时间转换成目标平台上对应的例程。

没有

8、该应用程序是2D/3D的图形应用程序吗？请描述之。

明确待移植的应用程序的复杂度。确认.NET Core上存在兼容的图形工具和开发工具，无论是系统默认提供的或者是第三方发行商提供的。

没有

9、应用程序使用了消息队列、共享内存、信号或者信号量吗？请描述之。

上述内容大部分能够方便的移植到.NET Core上。需要确认移植到.NET Core后，能够使原来期望的行为。

没有

10、应用程序或其中的组件，是多线程的吗？如果是，使用的是那种线程库?应用程序依赖开发平台特有的线程属性吗？

Linux支持多种线程库，但是现在以及将来的Linux发行版中，符合标准的线程库是NPTL（Native Posix Threads Library）实现。

组件没有多线程，也没有依赖开发平台特有的线程属性。

11、应用程序的某些操作提前假设某种特定的字节顺序吗？这在移植过程会成为问题吗？

该问题是关于应用程序的“大小端”（Littleendian，Big endian）问题。大部分.NET移植到.NET Core的目标平台都是Intel平台，该平台是小端的。也有可能要把.NET程序移植到RISC 类的大端平台。假设具体的大小端代码是不可移植的，并且如果移植不正确会导致不易察觉的错误。更糟糕的是，这些错误在移植时不会暴露出来，只会在系统测试的时候会突然出现问题，并且很难找到问题的根源。

没有假设字节顺序问题，.NET Framework帮助我们解决这个问题

12、开发平台使用的是那种编译器版本？

C# (什么版本？)
VB.NET(什么版本？)
F#(什么版本？)
平台特有编译器（Visual C++）
其他（请列出）

明确待移植的应用程序的复杂度。如果待移植的应用程序用的是C#/VB.NET或者F#编译器，则移植到Linux上会简单一些，因为.NET Core和.NET使用相同的编译器。如果用了windows平台特有编译器编译的应用程序，C++应用程序比C程序较难移植，应用程序可能使用了C++特性，例如模板。因为C++标准在不同厂商的编译器上实现不同，移植这种类型的代码比简单的C/C++代码要花费更多的时间。

使用C# 编写的应用程序，.NET Core和.NET使用相同的编译器，Mono也是兼容的编译器。

13、除了开发环境，应用程序还依赖其他的调试工具吗？例如内存泄漏调试器、性能分析工具、异常处理等。

这又回到了调查和分析依赖关系。Linux上可能有，也可能没有所需的第三方工具，这需要调查。谁提供许可？谁负责获取这些工具？如果需要第三方支持，谁来提供支持？

没有依赖其他的调试工具。

14、该应用程序是基于Socket的吗？如果是，它使用了RPC吗？请描述之。

虽然Linux支持标准的socket和RPC语义，但该问题的目的是确认程序的可移植性，比如.NET使用了WCF的RPC，.NET Core仅支持WCF的客户端访问，对于系统移植就很困难。问该问题可以搞清楚客户是否在应用程序里实现了不可移植的结构。该问题也可以引出其他问题，例如在测试阶段需要怎么样的配置。

没有使用RPC，使用的是HTTP Web API，依赖的组件Tencent.OA.Framework 依赖于WCF的客户端访问，需要移植到HTTP Web API 接口访问。

15、应用程序使用了第三方软件组件吗（数据库工具、应用程序服务器或其他中间件）？如果是，使用了哪些组件？

每一个第三方软件组件都会增加移植的复杂度。如果使用了任何第三方组件，都需要询问试了该组件的那个版本以及.NET Core上是否存在对应版本。第三方组件可能需要额外的时间去学习，甚至是配置或编译。

应用程序使用了第三方组件，

组件名称	版本号	Mono是否存在对应版本	.NET Core是否存在对应版本
System.Web.Http	4.0.0.0	存在	存在
System.Web.Http.Owin	5.2.3.0	存在	不存在
Microsoft.Owin.Host.HttpListener	3.0.0.0	存在	不存在
EntityFramework	6.1.3	存在	存在
Newtonsoft.Json	6.0.8	存在	存在
ServiceStack.Redis	3.9.71.0	存在	存在
Tencent.OA.Framework	1.0.0.0	存在	不存在
ExpressionEvaluator	2.0.4.0	存在	不存在
System.ServiceProcess	4.0.0.0	存在	存在
Microsoft.AspNet.Mvc	4.0.30506.0	存在	存在
Microsoft.AspNet.Razor	2.0.30506.0	存在	存在

16、应用程序时如何交付和安装的？使用标准的打包工具吗？安装脚本也需要移植吗？

Linux上一个标准的打包工具是RPM。RPM会在其他章节讲述。明确客户是否需要移植应用程序打包部分的内容。

使用XPlat 模式，没有使用打包工具，直接拷贝，部署运行。

17、应用程序或组件是64位的吗？有组件需要移植成64位的吗？

随着64位平台和操作系统的普及，该问题是要知道应用程序需要运行在什么体系结构的平台上。通过现代的编译器，大部分32为应用程序都可以轻松移植到64位环境上。需要考虑的一点就是移植和调试可能需要较长的时间。

应用程序都是64位的，不存在组件需要移植成64位。

数据库内容

1、应用程序当前支持什么数据库？请包括版本号。

现在几乎所有的企业应用程序都需要后台数据库。确认应用程序所需的数据库在Linux上可用非常重要。数据库产品以及版本之间的差别会导致增加很多移植工作。

应用程序支持的SQLServer 2008 R2，目前在Linux上处于预览版，需要移植到MySQL。

2、移植后的应用程序期望运行在什么数据库上？

除了问题1外，客户希望移植后的应用程序运行在Linux平台的什么数据库上？

希望移植后应用程序运行在Linux的MySQL 5.6上。

3、应用程序使用了非关系数据库或私有数据库吗？

现在还有很多应用程序使用NoSQL数据库，幸运的是大部分NoSQL数据库都运行在Linux上。任何私有数据库都需要移植到Linux上。确认运行数据库的代码在Linux上可用，这也是调查阶段工作的一部分。

应用程序使用了NoSQL 数据库Redis，Redis在Linux上运行良好。

4、应用程序是如何与数据库通信的？

编程语言（例如C#,VB.NET等）
数据库接口（例如ODBC，ADO.NET，Entity Framework）

确认所用的编程语言或接口在Linux上可用，确认是否由第三方厂商提供。

应用程序使用了Entity Framework 访问SQL Server，微软官方提供。

5、应用程序需要使用扩展的数据类型吗（XML、audio，binary、video）？

这个问题主要用来评估移植小组需要具备的技能。

应用程序使用Json 数据类型。

项目移植时间进度内容

1、应用程序在目标平台上的正式可用日期是那天？

该问题是要明确在制定移植进度计划时，是否有商业目标需要考虑。

需要在2017年春节前上线运营。

2、应用程序在目标平台上的移植工作已经开始了吗？

这可以帮助评估在正式开始之前发现的复杂度问题。

没有开始。

3、估计得移植复杂度是什么（低、中还是高）？

需要仔细分析对该问题的回答。现在很可能有一些新的因素在以前的移植经历中没有完全认识到。

移植复杂度适中，都是用C#语言编写的应用组件，需要移植的第三方组件也比较少，而且都有源代码。

4、在确定复杂度级别时，考虑了什么因素？

以前移植工作的任何信息都需要评估，并且与将来的Linux平台移植工作进行对比。

5、该应用程序曾移植到其他平台上吗？用了多长时间？需要多少资源？遇到过什么问题？

该问题试图把以前的移植工作和.NETCore移植进行比较。这只有在移植工程师的技术领导同时具有Windows平台和Linux平台移植经验的情况下，才会有用。

没有

6、你是怎样粗略估计项目移植时间和所需资源的？

应用程序或某些部分可能曾移植到其他平台上，知道向那些平台移植所花的时间会有些帮助。从那些移植过程得出的经验和教训会派上用场。吸取这些教训可以帮助你避免向.NET Core移植时重蹈覆辙。

测试相关的内容

1、请描述接收测试的环境配置。

服务器配置	用途	环境
tLinux 2.2/CentOS 7.2	API 服务器	Mono 4.6/Jexus/.NET Core 1.1/Nginx
tLinux 2.2/CentOS 7.2	数据库服务器	MySql 5.6+
tLinux 2.2/CentOS 7.2	Redis服务器	Redis 3.2
Windows Server 2008 R2	原API服务器/数据库服务器	SQL Server 2008R2

2、单元测试需要什么样的网络和数据库配置？

3、移植测试需要多少时间和资源？

4、是否已经建立了测试脚本和性能度量标准？

5、需要运行一些基准测试来进行比较吗？

6、性能数据在当前平台上可用吗？

7、最后执行性能测试是什么时间？

所有测试相关的问题都适用于软件程序在Linux平台上的测试。问这些问题还可以引出其他一些与移植测试脚本和测试工具有关的问题，而这些可能会增加整个项目的风险和时间。要重点关注客户对问题1的回答。问题1和接收标准有关，这些标准需要各方在移植开始之前都同意。一个接收标准的例子是：模块A和B应该通过测试用例c和d，并且没有错误。当达到测试标准后，移植可以说是完成了，正式的QA测试接着就可以开始了。