📢欢迎点赞：👍 收藏 ⭐留言 📝 如有错误敬请指正，赐人玫瑰，手留余香！
📢本文作者：由webmote 原创
📢作者格言：新的征程，我们面对的不是技术而是人心，人心不可测，海水不可量，唯有技术，才是深沉黑夜中的一座闪烁的灯塔！

序言

如果你接管了别人的园子，不管什么原因，总有一堆坐落在园中的器物，或是古旧假山，或是年旧失修的池塘，又或是不合时宜的零散花卉。

当你扛起锄头，想对这些旧物下手的时候，最好等等，先坐在旁边的凉椅上，打开Apple中的正念，闭上眼睛，想想下之前的主人，为什么这样做。

而我现在，面对就是类似的情景，只不过接手的不是园子，而是来自于远古时期的.Net Framework4.5的项目…

1. 为什么升级

项目目前使用VS2015管理，当然如果使用VS2022打开也不是办不到，稍微调整下.net Framework的支持，还是很容易做得到的。

老旧主人，应该也不是一个怀旧的人，不是不愿意看到新的事物发生，而是在旧有的圈子里，已经进入到一个舒适的状态，因此就没有大的动力进行革新，为什么需要花费更多的时间在不产生更多价值，或者是明显价值的事情上呢？

并且一旦进行革新，必然会遇到更多未知的风险，这些风险点，当然是可以解决的，但时间和精力的付出也是必要的，在没有更多压力的情况下，一动不如一静！

我臆测着老旧主人的心理，大概也不一定准确，只是给自己的行动找到支持的理由而已。每个人都在为自己的行为找各种理由，以满足自己就是行动正确性的心理。

2. 行动

已经有足够的理由说服自己了，那么就行动起来。
我给自己制定了一条路线：

升级编辑器为宇宙第一的 VS2022；

2. 升级项目为.NET 6 ,不幸的是，该计划夭折了，原因可能就是动作太大，扯到蛋了。

升级项目为 .NET Framework 4.7
升级类库为 .Net Standard 2.0
坐等结果

2.1 升级编辑器

借图一张，希望莫怪，如果需要支持4.5框架，那么还是需要一些步骤的。

这里有个教程，请参考：升级框架库

2.2 升级项目为 .NET Framework 4.7

修改解决方案文件，更改目标为4.7

<TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>

修改App.config文件

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
  </startup>
  <runtime>
    <!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false'  -->
    <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
  </runtime>
</configuration>

修改nuget包文件 package.config内的包目标为

package id="WebActivatorEx" version="2.1.0" targetFramework="net472" />

2.3 升级类库

这个步骤不是必须的，新的类库可以构建为 net standard类型，注意需要2.0版本。

<TargetFrameworks>net472;netstandard2.0</TargetFrameworks>

3. 坐等结果

如果一切顺利，到这里应该可以结束了。

不过有一个新的地方需要特别注意，这里会出现许多的问题。
包引用，类库冲突等问题。

由于就项目采用package.config来管理nuget包，而这种方式在VS2017时已经被升级为 PackageReference 方式。

默认情况下，PackageReference 用于 .NET Core 项目、.NET Standard 项目，以及面向 Windows 10 Build 15063及更高版本的 UWP 项目（C++ UWP 项目除外）。

.NET Framework项目支持 PackageReference，但当前默认为 packages.config。若要使用 PackageReference，请将 packages.config 中的依赖项迁移到项目文件中，然后删除 packages.config。

在项目文件内表现为：

<ItemGroup>
    <!-- ... -->
    <PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0" />
    <!-- ... -->
</ItemGroup>

在VS内的选项中，可以配置默认包类型，如图修改：

该方式的优势集中在如下方面：

在一个位置管理所有项目依赖项：与项目的引用和程序集引用一样，NuGet 包引用（使用 PackageReference 节点）直接在项目文件中进行管理，而不是使用单独的 packages.config 文件进行管理。
顶级依赖项的有序视图：与 packages.config 不同，PackageReference 仅列出那些直接安装在项目中的 NuGet 包。因此，NuGet 包管理器的项目文件不会与低级依赖项混在一起。
性能改进：使用 PackageReference 时，包保留在 global-packages 文件夹中（而不是解决方案中的 packages 文件夹中），因此，PackageReference 的执行速度更快，但占用的磁盘空间更少。
更好地控制依赖项和内容流：使用 MSBuild 的现有功能可以有条件地引用 NuGet 包，并选择每个目标框架、配置、平台或其他透视的包引用。

如何升级呢？

在“解决方案资源管理器”中，右键单击“引用”节点或 packages.config 文件，然后选择“将 packages.config 迁移到 PackageReference…” 。
检查任何的内容资产，修改为 contentFiles
包的 content 文件夹中的资产不受 PackageReference 支持，并且将被忽略。PackageReference 添加了对 contentFiles 的支持，以便获得更好的可传递支持和共享内容。潜在影响：content 中的资产不会复制到项目中，依赖于这些资产的项目代码需要重构