从VBA到VSTO的一些想法

最近学习了李永富老师的《VSTO开发入门教程》，跟之前的VBA知识对比下，有很多感触。

简单比较

说说VBA

VBA（Visual Basic for Application）是通过VB语言来操作OFFICE文档、程序以及其他软件产品的技术，使软件的用户扩展性理论上无穷大。

Office中VBA需要启用开发工具，即可录制宏，使用宏，插入模块等，非常的方便，尤其是自定义函数，不需要任何其他操作，只需要关心函数本身的逻辑，用户可以通过录制宏来学习任何操作的代码实现方法，极易成长。

但同时，VBE（Visual Basic Editor）（就是office自带的原生编辑器）真是上世纪九十年代既视感，习惯了IDEA这种强大的IDE的同学肯定感觉在记事本里面写代码一样。

聊聊VSTO

VSTO是一门新技术（相对于VBA）了，其实就是用.Net的形式来写Office程序。

当然了.Net不仅仅支持VB，也支持C#，这意味着，你既可以用熟悉的VB来写（忽略VB.NET和VBA细微的语法差异），也可以用更强大的C#来写，相比较而言，可以用C#来实现更复杂的需求，比如多线程，比如面向对象（真正的面向对象，VB更像是面向过程，不过支持面型对象而已）。

中间操作遇到一个问题，即VBA的方法，函数，C#中不一定有，或者使用方法与场景不同，这就是.Net的长处了，.Net是一门技术，不是一门语言，你可以直接在C#中使用VB的库，就像使用C#自己封装的库一样（比Java的JNI方便的不要不要的）

但是，需要装一个VS，具体版本取决于目标office程序，如我的office是2016，就需要装一个VS2017版本，大学时就体验过微软的豪华，现在装一次VS2017，真是有感触，豪华永无止境啊，上来就是10G+。不过宇宙级IDE总是对得起它的空间的。

话说回来，一个简单的文档操作，至于这么大动干戈吗？
生命在于折腾！

其他操作方式

其实除了微软提倡和支持的VBA和VSTO两个方式外。其他很多编程语言都可以直接操作Office文档。

因为Office文档本身就是一个xml文件，xml本身又是一个文本文档，或者说，只要能读写文件，处理字符串的变成语言，理论上都支持操作Office文档。

操作office文档本质就是操作一个复杂的XML文件，底层使用xml文档操作技术（如DOM，SAX）封装一些常用方法，属性，类库，呈现出来一个框架或是技术，成为这个编程语言操作Office的利器。

现在操作Office文档生态较好的语言有，JavaScript、Java、Python。

生态最好的当然是C#了。为什么有C#？它不是本身就支持吗？，C#除了使用VSTO技术操作Office文档外，还可以直接通过控制台或是Form或是Web项目using相关命名空间，即可直接操作Office。

既然有这么多语言可以支持，那为什么要用VS，要用C#.Net呢？

兼容性
微软没有开放Office的API接口，其他语言类库是直接凭经验解析，很可能有些老版本，或是特殊一点的文件，又或者新文件解析出错，.Net原汤化原食。
可扩展性
从数据区到功能区，到各种操作窗格，用户控件，真的是其他非MS系语言可以比拟的。
学习成本
用户不需要整天去开着某个类库的官方文档来学习，想知道某个操作如何用代码实现，直接录制宏，查看宏代码（VB），文档对象模型都是大致相同的，然后用C#的方式实现，遇到问题，F1查看帮助。

工具推荐

VS可以直接使用最新版（现在是2017）的社区版本，免费且完全够用。

习惯IDEA或是（其他JB系列产品）的，可以装上ReShaper插件，使用IDEA快捷键和编辑方式。

习惯eclipse也可装上asEclipse，体验visual studio for eclipser

比较结论

小需求用VBA

毕竟轻量

大需求用VSTO

强大

文档级别需要自定义函数尽量用VBA

VBA简单，VSTO自定义函数过程太繁琐

文档级别不需要自定义函数用VSTO

不自定义函数，C#写起来就是比VB舒服（个人感觉）

外接程序界别用VSTO

这个不多说了，可以直接打包做成EXE给别人。

保证兼容性优先，使用VBA

大家都是盗版，拿什么保证客户机装了vsto for office