.net4.6.2和.net4.7.2关于代码优化的一个差别

一 问题出现

近期在开发中发现逻辑基本没改变只是升级框架之后的程序无法运行了，前后远程客户电脑百思不得其解，首先客户电脑是Window7的，所以想到原来那边还没有配置过.net framework 4.7.2，但是主页却能运行，原因是.net 4.x是本身升级，所以之前在config文件中指定的还是v4.0，如下

	<startup>
		<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" />
	</startup>

修改指定版本后，终于需要.net framework 4.7.2了，于是乎就先安装环境v4.7.2，安装完补丁KB3004394、KB3118401、KB4019990，再安装NDP472-KB4054530-x86-x64-AllOS-ENU.exe离线安装包。

    <startup>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />
    </startup>

省略N个步骤之后，经过一系列折腾之后安装成功了，可喜可贺，正在我一阵欣喜过后迎来了第一盆凉水，程序和原来一样正常打开，但是死活运行不起来，我以为是因为ModbusRTU通讯库更改的问题，还原之后依旧如此，于是乎我怀疑自己改掉了一些业务逻辑导致现场这个情况。

二 纠结辗转

在怀疑业务逻辑之后，我开始搭建本地环境，因为没有硬件支持，其中又使用到了ModbusRTU，于是乎我就用ModbusSlave模拟使用发送和接收，这还不得不说我们业务使用到了其他的功能码，所以还是在报错，于是乎我在排查流程、配置、PLC通讯等等之后，决定就着现状一步一步走，终于模拟位置、模拟运行状态、到了发送运行命令那里，我猛然在ModbusSlave上看到一个值768，怎么这个数字这么熟悉，但我依旧不以为然，以为是发送数值没成功，于是乎走到了发送那里，一遍一遍的走发送，一遍一遍的条件断点到发送3的命令上，大概有个半小时，实在百思不得其解，发现了这样几行代码

                //转换有些问题，uint16->int16
                var usa = BitConverter.GetBytes(us);
                usa.Reverse();
                aList.AddRange(usa);

这里转换有些问题早就存在，但谁也不知道这里究竟是什么问题，因为原来的代码是这样写的

                //转换有些问题，uint16->int16
                aList.AddRange(BitConverter.GetBytes(us).Reverse());

这这这这，这让我喜出望外，可是这个问题很早就改了，一直没出过问题啊？我一时间丈二的和尚，呆住了，于是我不改代码，咱看看编译出来的dll反编译是什么鬼。

三 代码优化这个鬼

我先将组件改成兼容.net462和.net472的生成方式，然后放到ILSpy中，于是乎看大如下反编译内容

.net 4.6.2 如下

.net 4.7.2 如下

这就是问题症结了？让我如何接受，接受不了，于是我将代码优化关掉。于是乎，两者一样，一时间愣在原地，不知道谁更懂我了......

<Optimize>false</Optimize>

四 课后总结

看来这个代码优化还是有一定差异的，我想起来一个using的代码优化，让我在组件库中很多地方都是禁用这个代码优化的，但是此时代码优化还帮我掩盖了很多历史真相......