及时的软件现代化有助于保持软件的安全、高效和符合法律要求。但是一些现代化的类型，如重构，需要大量的资源来执行，同时又有引入新bug和漏洞的风险。
对于基于。net技术的软件来说，重构还有一个很好的选择——实现。net标准。它允许开发者升级他们的软件而不重写代码，使他们的软件更便携和灵活，并引入新的功能。
在本文中，我们将讨论什么是。net标准以及它在。net生态系统中所扮演的角色。我们还将向您展示如何将项目迁移到。net Standard，以使其跨平台并支持现代特性。
这篇文章对于那些想要在不投入大量时间和金钱的情况下改进他们的软件的遗留。net应用程序的所有者和开发人员是很有用的。
写的:
亚历山大·M。
软件开发人员,
Web开发团队
和
Hennadii Z。
软件分析师,
Web开发团队
和
维塔利·Panasyuk
发展的领导者,
Web开发团队
内容:
为什么要现代化遗留应用程序?
IT技术的变化和改进如此之快，以至于大多数软件在发布后不久就需要现代化。以下是Gartner如何定义需要升级的遗留软件:
遗留应用程序或系统是基于过时技术的信息系统，但对日常操作至关重要。用基于新的和不同技术的系统替换遗留应用程序和系统是信息系统(is)专业人员面临的最大挑战之一。当企业升级或更改其技术时，它们必须确保与仍在使用的旧系统和数据格式兼容
软件现代化迁移、重写或移植软件以实现现代语言、平台、库和功能是一个棘手而复杂的过程。通常，软件现代化过程包括三个关键阶段:
- 评估遗留软件的当前状态并定义现代化目标
- 选择现代化类型，规划现代化进程。在这个阶段，开发人员和业务管理人员一起工作来定义为现代化和可能对业务的影响而分配的资源是很重要的。
- 典型的开发和测试过程
及时的软件现代化为公司提供了许多好处:
所有这些好处都可以显著减少组织的IT支出。例如，美国政府打算花在2019财年，IT领域的投资约为900亿美元。其中近800亿美元用于运营和维护现有的IT系统，其中一些系统已有51年历史。使该软件现代化以满足现代开发标准可以大大减少维护工作和费用。
对于希望从长远来看节省IT预算并提高运营效率的公司来说，定期的系统现代化是必须的。实现软件现代化最常见的方法之一是重构代码。然而，这种方法也有许多缺点:
- 重构和测试代码需要时间。要重新编写应用程序代码，开发人员需要了解遗留技术和使其现代化的方法。应用程序越老，开发人员就需要更多的时间将其提升到现代标准。重构之后，软件必须从头开始测试，这也需要很多时间。
- 有引入新bug的风险。对遗留代码的每一次更改都带来了创建新错误的风险，特别是当重构不是由构建应用程序的相同开发人员进行时。
- 重构伴随着可能的停机时间和业务损失。在重构过程中，软件可能不稳定、效率低下或不可用。这将影响使用该软件的组织的运行。
由于这些缺点，重构应用程序可能不是实现其现代化的最佳方法。使用基于。net技术的应用程序，可以在不重构的情况下将新技术引入遗留系统。特别是，您可以将。net应用程序迁移到。net标准，从而将其转变为跨平台的。net解决方案。
在本文后面，我们将分析这种迁移的一个实际示例。但首先，让我们探讨一下什么是。net标准，以及它在。net生态系统中扮演的角色。
开始使用。net标准
. net生态系统包含的不仅仅是众所周知的. net框架、c#和Microsoft Visual Studio。它还包括:
- net核心-一个用于Windows、Linux和macOS应用程序的框架，旨在帮助开发人员在。net中创建跨平台应用程序
- 莫诺-类似于。net Framework的运行时，用于Android, iOS和macOS应用程序
- Xamarin的—支持iOS、Android、Windows应用开发的开源平台
- 普遍的Windows平台-支持Windows 10、Windows 10 Mobile、Xbox One和HoloLens开发应用的平台
- 团结-实时开发2D和3D应用的平台
对于如此多的运行时和平台，开发人员需要跨所有实现使用一些通用逻辑，以便统一它们并允许代码重用。这就是。net标准。
net标准是。net api的正式规范。这里的关键字是正式的，因为它不是开发人员通常安装在他们的系统中的东西。它的目的是在不同的。net运行时和平台之间共享相同的代码标准。使用。net标准进行系统现代化有助于使。net应用程序更加灵活，并在。net生态系统中跨平台工作。
在。net标准实现之前，开发人员使用便携类库(pcl)来重用它们的代码。但这些库并不是万能的解决方案，因为它们只针对特定的。net运行时。net Standard是pcl的现代替代品，它拥有高级API，不依赖于目标平台，并为平台无关的开发提供了更健壮的选择。
. net标准的版本是向后兼容的:每个. net标准的新版本都包含了以前版本的API界面。
所有。net组件都支持。net标准的特定版本。它的文档兼容性列表如下:
注意。net组件的版本号对应于。net标准的最小支持版本。例如，不可能让。net标准2.0应用程序以。net Framework 4.5为目标。
简单地瞄准最新的. net标准版本并不总是最好的主意。例如，使用。net Standard的最老版本可以使库与更多的项目兼容。但是对于应用程序开发，我们希望使用最新的。net标准和最新的特性和api。
现在，让我们看看如何将应用程序迁移到。net Standard。
将一个示例解决方案迁移到。net标准
作为一个例子，我们将采用一个针对。net Framework 4.7.2的解决方案，并将其重新定位以支持。net Standard 1.5。该解决方案有以下依赖关系:
首先，我们应该使用。net标准分析现有代码与目标版本的兼容性net可移植性分析仪扩展。一旦安装了扩展，我们需要打开项目上的上下文菜单，并单击可移植性分析器设置。
图1. . net可移植性分析器对话框
然后，我们将转到General部分，并选择所需的目标平台、其版本和输出格式。
图2。选择目标平台
之后，我们将在上下文菜单中选择Analyze Project Portability选项卡。
图3。分析项目可移植性选项卡
这个选项卡中的信息将在以后成功地将我们的项目迁移到。net Standard中。
现在，我们可以开始迁移过程了。第一步是从EntityModels项目中编辑.csproj文件。该文件包含. net程序集的描述，包括文件、配置、引用程序集和引用包。我们需要将项目中的.csproj文件的内容替换为. net SDK中的.csproj文件模板的内容，并填写所需的字段。
文件内容看起来像这样:
接下来，我们将移植DataMaps项目，它依赖于其他项目和外部包:
图4。在移植数据地图之后分析项目可移植性选项卡
我们将手动更改DataMaps项目中的.csproj文件，方法与之前的项目相同。在我们的操作之后，文件看起来像这样:
在执行这段代码之后，我们看到CS0246错误．要解决这个问题，我们需要安装一个NuGet包或添加一个对DLL的引用。有时候，外部包支持特定的平台，并且对于每个平台有各种各样的依赖项列表。在我们的案例中，我们决定在这个项目中引用另一个组件:
在分析项目可移植性选项卡中，我们可以看到尚未迁移到。net标准的项目并不完全支持它。因此，在重新定位到。net标准之前，我们需要对它们进行操作。
图5。用我们解决方案中的所有项目分析项目可移植性选项卡
现在，我们需要开始重新处理Data、Shares和ViewModels项目。让我们使用ViewModels程序集转到分析器报告和筛选记录的Details选项卡。
图6。ViewModels项目的详细信息
我们可以看到，用于验证数据的DataAnnotations属性在。net标准中不受支持。在本例中，我们需要用来自FluentValidation扩展。
在这些操作之后，让我们再次运行分析器。
图7。我们的三个项目现在以。net标准为目标
接下来，让我们将Shared项目迁移到。net Standard。再次，我们需要在分析器的Details选项卡中仔细查看它，看看它是否支持。net标准:
图8。共享项目的详细信息
如您所见，这个项目只支持。net标准2.0和更高版本。为了不降低它的等级，我们将把Shared项目及其依赖项(EntityModels和ViewModels)定位到。net Standard 2.0。我们仍然会将所有其他不依赖于Shared的项目迁移到。net标准1.5。
下面是我们如何针对Shared项目及其依赖项:
我们将以同样的方式将基础设施项目迁移到。net标准1.5。
现在，是时候在Data项目上运行分析程序了，但是这次我们的目标是。net标准2.0而不是1.5。
图9。只有Data项目不以。net标准为目标
这一次，结果看起来更好。剩下要处理的唯一事情是Data项目。
图10。数据项目的详细信息
正如我们在之前迁移的项目中所做的那样，我们将改变Data项目中的.csproj文件，以支持。net Standard，并重新安装NuGet包。
最后，我们可以构建并尝试运行应用程序。然而，如果在输出文件夹中缺少一些NuGet dll，应用程序将不会运行，我们将收到错误。为了解决这个问题，我们必须在所有。net标准项目的。csproj文件中添加以下代码:
现在，我们可以尝试再次构建和运行应用程序。构建它之后，我们得到另一个与ConfigurationManager相关的错误。不幸的是，. net标准不支持ConfigurationManager。为了解决这个问题，我们可以将项目更改为multitarget，以允许它同时针对。net Standard 2.0和。net Framework 4.7.2。我们可以在.csproj文件中使用以下代码:
现在，我们必须相应地重写需要ConfigurationManager的源代码。在本例中，这是我们需要使用的惟一一点重构。源代码应该是这样的:
这个项目最初是为。net Framework 4.7.2构建的，所以当它需要使用ConfigurationManager时，它会从。net Standard 2.0重新定位到。net Framework 4.7.2。
结论
对于任何过时的软件来说，遗留软件现代化都是必须的。使用遗留IT系统只会导致更高的支持费用、安全漏洞和生产力损失。但是现代化本身也带来了许多挑战，比如可能的停机时间、产生新漏洞的风险以及花费太多的时间和精力。
对于基于。net环境的应用程序，可以通过使用。net标准更新应用程序来避免重构。在本文中，我们展示了如何在不重写的情况下将。net Framework项目迁移到。net Standard。
在Apriorit,我们专门的。net开发团队始终确保我们开发的。net项目符合客户的任务要求，并遵循最新的编程标准。联系我们，我们会处理升级您的遗留系统!
