平常我们开发一些插件过程中，肯定不可能一口气把所有功能开发完，或者开发好之后，给到用户手里使用过程中，不出现任何错误问题。
使用传统的VBA方式开发，开发过程简单，布署也方便，直接把Excel的xlsm或xlam文件发给用户，用户打开就可以使用，但现在问题来了，如果出现前面所说的程序有bug和需要增加新的功能，我们怎么办？
一般情况下，我想都是需要重新开发一个新的xlsm或xlam文件，然后重新发给用户，这当中如果频率太频繁，用户手里积累了好多个xlsm或xlam，也很难分清具体哪个是最新的（就算文件名上可以标识，但很难保证每个用户都每个用户都记得去下载最新版的）。最终的局面估计是双方都怨声累累，用户报怨开发者太屎了，老是功能出错，开发者也报怨用户使用千奇百怪，哪能想得完全所有的意外情况，程序有bug也是再正常不过的事情。
现在假如我们使用vsto开发，使用其中的clickonce的布署方式，又会有怎样的改进呢？
首先，上回说到的数据和代码的分离，在这里就可以看到它的价值所在了，用户只需关注自己的工作薄上的数据加工处理，代码功能部分有问题不要紧，开发者只需把代码修复好，用户照样可以使用旧的文档来载入新的修复的功能或追加的功能，不受代码更新的影响，用户的体验和目前的流行的BS架构下的程序几乎一样，甚至更好。
用户使用Excel就像使用一个网页浏览器一样，每次打开Excel，都能得到最新的功能，而整个升级过程，完全不需要用户做半点操作，一切都是自动完成，瞬间完成，代码和数据分离，整个更新过程只是代码部分，不需加载和传输用户的数据部分。
Vsto开发的插件，除了自动升级方面，有很好的体验，其实还有对代码的安全性的把控，也是可以做得非常好。
例如传统VBA是以文档的形式和用户做传输，用户对文件的来源和文件内的代码的安全性很难把控，就算相信某个开发者，但也很难保障到最终拿到手里的文件是出自此开发者的，传输过程中没有被恶意修改过的等等。
现VSTO的程序为何能做到不需用户干预，直接就自动更新了呢，如果出现像传统VBA开发那样，更新的代码被篡改了，然后用户不知情下代码已经植入了用户的机器，这样的情况岂不是很可怕。
所以VSTO在做自动更新机制的过程中，有了两道验证保护，
1、验证程序是开发者开发的，用证书的方式来保证，证书是一一对应的，开发者给用户电脑分发证书，用户电脑安装了证书，就证明用户是信任开发者所开发的一切程序，开发者因为是事先被用户所知的，也需要对自己所开发的程序负责，出现问题是不能抵赖的，因有证书为证，开发者发布的程序里带有一把钥匙，用户手里的证书是另一把钥匙，只有两把钥匙在一起，程序才能被解开使用，两把钥匙是一一对应的，世上仅有这两把钥匙能够开启这个程序。
2、用户机器需要信任开发者给程序存放自动更新的路径（网站或共享UNC路径），就如我们xlsm文件我们存放在本机时，只对某个文件夹路径的xlsm可以开绿灯放行，如果不在这文件夹内的xlsm文件，默认是不能打开宏代码。同样的发VSTO的方案中，用户也需要手动配置好信任开发者存放dll等代码文件的位置，如果开发者不按要求放到某个位置，用户机器可以拒绝对其信任。
有了这两层的信任机制，用户就可以完全地相信开发者的程序，不需要每次都被询问是否信任或每次都要自己去识别这些文件的可靠性等等。
视频演示：
