【爬坑】.Net编译环境导致的问题

1. 背景：

• 项目中遇到一个串口设备，通过调用它自带的.dll动态链接库通信，最开始在.net framework4.7.2的框架下设备能返回数据（正常通信）。但是换到.net 6.0的框架后，可以运行（没有报错），但是不能得到设备返回的数据了。

2. 错误的解决思路：

• 当时觉得是框架的问题，反编译可以看到该.dll的反射，但是没有源码不能修改。
• 如果尝试用.net upgrade assistant强行升级框架，该.dll文件只会出现提示Cannot add reference "xxx.dll" to project "xxx" because their target framework are incompatible ,没有任何实际作用。

3. 正确的解决思路：

• 不管是.net framework 4.7.2 还是 .net 6.0，当时都是默认的Any CPU,这个环境造成了这个问题。
• 该串口设备在运行的时候环境是基于x86的，所以在.net 6.0的框架下，把CPU类型选成x86就行了。

4. 获得的经验：

• 1. .net upgrade assistant作为一个升级框架的官方免费工具，还是很好用的。用到visual stiduo的拓展工具下载它，如果发现下载很慢的话，右键打开WLAN网络属性，把ipv6给关了，会好的多。
• 2. 在.net framework下使用AnyCPU能正常的原因如下图，.net framework 4.5以上默认首选32位：
     
  • 在32位系统下，运行32位程序
  • 在64位系统下，运行32位程序，但是可以获得4G内存
  • 在ARM下，运行32位程序
  • 那么AnyCPU(Prefer 32-bit) 和x86有什么区别？实际上在ARM系统，只能使用 AnyCPU(Prefer 32-bit) 运行32位程序，如果选择x86就无法运行。
  • 为什么需要在64位的设备使用 AnyCPU(Prefer 32-bit)，因为如果存在一些库只能在32位程序运行，那么就需要运行的程序是32位，所以需要使用这个方法。
  • ARM32/ARM64是ARM CPU下的32位或者64位系统；
• 3. 在.net 环境下没有这个默认选项，在64位的电脑上用AnyCPU表示用anycpu编译的可执行文件将在64位CLR上执行。
• 4. 手动改为x86就行，如图：
     
• 5. Visual stiduo 引入的.dll文件默认在bin文件下