32位编译的VSTO插件迁移到64位Office产品中的异常一例
前段时间,我发布过一篇随笔《VSTO中使用线程钩子响应鼠标键盘事件》,当时的编译环境是32位的,后来在64位的Office中,原本以为会顺利在wow64下兼容运行的,但遗憾的是,启动文档后只要有鼠标键盘消息就会抛出异常。截图如下:
可想而知,多半是不恰当的数据类型引起的,于是对代码进行调整,在MSDN发现有这样一段描述,引起我的注意:64-bit Applications
Many assemblies run identically on both the 32-bit CLR and the 64-bit CLR. However, some programs may behave differently, depending on the CLR, for one or more of the following reasons:
-
Structs that contain members that change size depending on the platform, for example, any pointer type.
-
Pointer arithmetic that includes constant sizes.
-
Incorrect platform invoke or COM declarations that use Int32 for handles instead of IntPtr.
-
Casting IntPtr to Int32.
一开始我并不明白为什么单独把IntPtr指出来,仔细查看IntPtr的类型说明,才明白,原来IntPtr在不同的操作系统下指向的地址大小是不同的,也就是说,64位操作系统下使用64位的Office,它指向的类型是Int64,而并非Int32,所以在我先前的代码中,凡涉及到IntPtr转int的语句,均会出现算术溢出的异常。在了解这些后,所做的改动就比较明确了,为了保证同时在32/64位平台下执行,把IntPtr全部改为int,如果要区别对待的话,应该显式的把IntPtr与Int32或Int64做转换,目标就是使用一致的数据类型。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 为什么说在企业级应用开发中,后端往往是效率杀手?
· 用 C# 插值字符串处理器写一个 sscanf
· Java 中堆内存和栈内存上的数据分布和特点
· 开发中对象命名的一点思考
· .NET Core内存结构体系(Windows环境)底层原理浅谈
· 为什么说在企业级应用开发中,后端往往是效率杀手?
· DeepSeek 解答了困扰我五年的技术问题。时代确实变了!
· 本地部署DeepSeek后,没有好看的交互界面怎么行!
· 趁着过年的时候手搓了一个低代码框架
· 推荐一个DeepSeek 大模型的免费 API 项目!兼容OpenAI接口!
2006-04-13 GridView&ObjectDataSource新特性小记 懒人篇(一) 分页上路