记一次编译转码程序遇到的坑

​大家好，我是peachesTao，今天给大家分享一下工作中遇到的一个C#转码工具的编译问题及解决过程。

背景

老师每次上课，都会准备ppt课件，上课前会将课件上传到上课app，上传后调用转码程序转码，将ppt课件转成html格式，之前这个转码程序设置的最大可支持的ppt文件大小是25M，很多老师反映他们有些课件超过25M，希望能支持更大的课件上传。经过内部讨论决定，将上限提高到30M。

写这个转码工具的人已经离职了，我的一个同事尝试着修改代码，发布到测试环境发现无法转码，他之前没写过C#，只是凭借其他语言的经验去研究的，花了好几天时间。后面我跟公司说我之前写过C#，可以接这个需求（之前我不知道他没写过C#，否则当时就直接接过来了）。

准备工作

这个程序运行在window平台，只能在window系统编译和调试，虽然.net Core可以跨平台， mac上也可以用vs code编译和调试C#代码，但从.net frameword迁移到.net Core成本比较高。

我那个7年前买的老爷机，华硕笔记本电脑又可以派上用场了，虽然这台电脑跟现在动辄4核CPU的电脑运行速度比起来简直是龟速，但还能凑活着用，毕竟只是难得用一下。接下来安装好git和公司的vpn工具。

开始编译

从gitlab拿到源码编译时提示五个dll文件引用找不到，DigitalOfficePro.Html5PoinSdk.dll，Html5Point.dll，Office.dll和Microsoft.Office.Interop.PowerPoint，前三个文件是第三方转码类库文件，后面两个是微软office中的库文件，虽然项目中没有包含这几个文件,但从文件引用属性可以看出版本号。

经过一番搜索，下载安装了Html5Point sdk，解决了前三个文件的依赖，后面两个文件直接在网上单独文件下载的，重新添加引用后，编译报错，提示“错误 CS1752 无法嵌入互操作类型“ApplicationClass”。请改用适用的接口”，这个错误本来可以通过设置dll文件的“嵌入互操作类型”设置为False解决的，见下图。

但当时主观判断是Office.dll版本不兼容，为此尝试过不同的版本，结果都报同样的错，既然网上的版本都不能解决问题，只能本地安装ofiice 2010办公软件试试了，为什么要安装office？

其实Office.dll和Microsoft.Office.Interop.PowerPoint.dll都来源于office，当office安装好后在C:\Windows\assembly目录下会生成这两个文件，至于为什么是2010版本，因为Microsoft.Office.Interop.PowerPoint.dll要求的版本是14.0， 他们的关系是2010=14.0，2013=15.0，2016=16.0。

安装office遇到的坑

下载了一个office 2010 64位的安装包，安装的时候提示：“已经安装了32位的office版本”，于是先卸载32位的office，卸载时报错：“指定的账户已存在”，于是又各种找资料，重新安装32位再卸载、360强制卸载等办法都不行，最后通过删除注册表成功安装了64位的office 2010。

office安装好了，之前的那个“无法嵌入互操作类型”的错没有了，再次编译成功，此时终于松了一口气：“终于搞定了”，但快乐总是短暂的，还没来得及享受现实又把你带入了另一个问题：“输入ppt文件路径进行转码时程序报错：“库没有注册”。

打印出来的堆栈信息显示是Html5Point中convert方法抛出的异常，封装在Html5Point.dll中无法进一步追踪，也没有提示哪个库没有注册，然后又开始搜索资料，搜到的都是其他软件报的这个错，尝试过卸载重新安装sdk，都无效。

曙光重现

折腾了几天之后有点身心疲惫了，难道要祭出大招：重装系统？非要逼不得已一般不会这么干，因为没有镜像系统，重装后所有软件都得重装。就在这无助的时候，一次产品需求评审会议时间到了，会议前跟一个同事说了下我这个事，他说：“可以在测试机器上安装开发环境，编译试试“。

这句话让我有了新的思路：测试机上的依赖环境肯定是全的，为什么不把程序直接放到测试机上测试？只要程序引用的入口dll没有问题其他的依赖应该就没问题，程序是在服务器跑的，本机只要编译通过就行。

有了新的方向后马上把程序传到服务器，输入ppt路径转码成功，正常生成html文件。

总结

这次经历感触颇多，只需要改一行不到的代码就能实现的功能却花费了好几天的时间，总结以下几点：

• 程序中的任何报错在没有100%确定原因时不能主观下结论，否则会带来很多麻烦。

• 在各种方案都尝试过，折腾了好几天都未果时，跟其他人聊聊，或许他们会给你一种不同的思路，往往不一样的思路最终能解决问题。

• window系统上开发坑太多，受限于闭源，开发者无法调试底层的代码，让排查问题变得困难，这大概是是我转向go的一个原因。微软也意识到这个entity，几年前推出了.net Core跨平台技术并开源。

如果这篇文章对你有帮助，可以关注我的公众号，第一时间获取最新的原创文章