前言
最近项目中,需要使用到 Excel 导出,找了一圈发现没有适用于 .NET Core的,不依赖Office和操作系统限制的 Office 组件,于是萌生了把 NPOI 适配并移植到 .NET Core 的想法。
NPOI 的介绍不多说了,不了解的可以看一下 NPOI百度百科 的介绍,在此感谢瞿总和他的团队的贡献。
NPOI 的移植之路并非想象的那么容易,因为其依赖了 System.Drawing 和 System.Window.Forms 两个组件,还有一个第三方的 SharpZipLib 库,在 GitHub 克隆了最新的代码并且转换为 NetStandrad 1.6 编译之后,出现了数不清的错误,应该有上千个吧,在经过一天的努力之后(包括删除,修改,重写),错误数量已经减少到了100多个,50多个,20多个,编译通过。
在移植的过程中可以真切感受到当初NPOI的作者在写这些代码时候的辛苦努力,因为NPOI最初是基于 .Net Framework 1.1 框架写的,那个时候没有泛型,没有var,没有很多的现成的类库,全都是靠最基础的一些数据结构来实现,虽然里面的很多种写法在目前看来可以很大程序的精简,但是在当时的条件下 真的是不容易。
在通过编译之后,心里想着应该问题不大了,于是测试了一下,不幸的是,各种问题,又经过半天的调整之后,打算放弃了。 于是又去 github 上面搜索看看有没有其他什么解决方案之类的,无意间搜索到了一个 NPOI.Core 的一个项目,是一个老外移植的 NPOI 到Core平台,原来已经有人做了Core的移植了,克隆下来之后发现编译不过,又进去看了一下代码,这个库目前依赖于Windows平台,而我们项目是运行在CentOS的,其并不能在Linux上运行,看来还是空欢喜一场。
怎么办? 于是,又一次重构开始了,有了前一次的重构经验之后,这一次可谓是轻车熟路了,NPOI Core 库 里面使用了很多.NET Core netstandrad 标准不支持的 Hashtable 和 ArrayList 等数据结构,这些已经被新的泛型 Directory 和 List 替代了,还有依赖的 SharpZipLib 等压缩组件也都替换成了 NetStandrad 的实现,当然还有其他很多杂七杂八的就不细说了,最后,终于 netstandrad 1.6 下编译通过。
通过之后,本地 visual studio 下 新建了一个项目,简单测试了导出 Excel 的功能,没问题,也没有报错,心里很开心...。 这个时候我在想,最关键的就是能不能在Linux上正常运行了,其实这个时候我心里想我已经把依赖于.NET Framework 的各种类都换成了net standrad了,应该问题不大了。
然后在一顿 dotnet publish 之后,把部署包传到了 Linux 下进行测试,果然,运行通过,并没有抛出任何异常,而且Excel也生成了,把Excel传输到windows上使用office打开,完美...
然后紧接着就是继续各种测试了,在测试到 Word 的导出功能时候,出问题了。因为NPOI 天生对Word的功能支持的并不是很完善,心想是不是.NET Framewok下导出也不行啊,于是又新建的一个.NET Framework的项目,使用NPOI Team提供的 dll 测试,发现可以导出。然后就开始跟代码,各种测试,重构,最终Word的导出功能也没有问题了。紧接着又发到了Linux上测试,没有问题,心里的石头落地了。