XLA vs COM vs Automation与托管代码加载项

时间:2017-09-12 13:10:19

标签: automation com add-in managed-code xla

我需要您帮助决定最佳策略和技术,以便继续开发成功的内部VBA应用程序。

在我们公司(基于网络的财务信息分销商)中,多年来,我们开发了一个仅在我们公司内部使用的VBA XLA插件应用程序,它有助于将我们的财务信息数据库与Excel工作表,通过使用几个UDF,由ADO / SQL和其他业务对象逻辑支持。这个应用程序成为我们的一个坚实,快速和有用的工具,有点类似于旧的DDE链接,但比这更复杂和灵活。

最近,我们用基于SOAP的Web服务和XMLHTTP MSXML 6.0技术替换了系统的ADO / SQL部分,从字面上将我们的数据库放入云中。目标是将应用程序转换为可在公司外部使用的产品。这项工作已经完成,其表现相当好,具有所有功能,启动时加载,用户身份验证和会话控制登录/注销,与EXCEL的无缝集成,用户友好的消息,所有这些都在一个2.036Kb XLA加载项中完成文件,涵盖超过15.000行良好的VBA代码。但是,我们觉得它还不能像它一样分发......

我们认为,为了成功地将产品作为产品发布给我们的客户,必须将此应用程序转换为已编译的代码而不是已解释的VBA。有很多理由可以证明这一点,包括安全性,速度,稳健性等。但我们现在不需要了解这些细节。

我们的第一个想法是使用VB6和自动化设计器将我们的VBA代码快速转换为VB6自动化插件。除了VB6是旧技术之外,似乎自动化插件不是理想的解决方案,因为我们的应用程序需要与Excel事件和最终用户进行一些交互,至少在"登录"和"退出"进入基于Web服务的数据库(以及需要通过表单进行用户交互的一些其他功能),但似乎自动化加载项不适用于除UDF之外的任何其他内容。在这里,我们想了解其他自动化插件和最终用户交互的经验。

因此,COM加载项是下一个选项。同样,这些允许通过菜单按钮和命令进行交互,但不允许在工作表中使用UDF。或者我们已经阅读过了。此外,我们已经读过COM加载项可以作为自动化加载项(毕竟允许UDF),但它们将作为Excel环境中的两个独立实体(一个COM和一个加载项) ),一半不与另一方沟通。这对我们来说是不可接受的。同样,我们想要了解更多关于这方面的其他经验。

然后有托管代码(.NET,Interop和VSTO)作为其他可行选项。然而,虽然开始使用起来很简单,但目前还不清楚Interop是否会停留,并且目前尚不清楚托管代码的最佳策略是什么。同样,我们想要了解这个领域的其他经验。

所以,问题最终是:给定我们的要求(即启动时加载,通过基于SOAP的Web服务(MSXML 6.0)访问数据,UDF的功能,登录/注销会话控制,用户友好错误处理等),以及我们已经拥有15.000行良好的VBA代码,这是我们继续开发这个Excel组件的最佳技术,以使其成为一个易于安全分发的产品?在这方面的所有评论和想法都非常受欢迎。

2 个答案:

答案 0 :(得分:0)

您项目的精彩摘要。

我也很好奇其他人对这种任务的“正确”解决方案的看法。但这不是一个容易的决定。

我的简短回答是“坚持使用VBA”,除非您真的担心从优秀的VBA插件中窃取您的代码。

我选择VBA的原因是我使用VSTO / COM的时间越长越好我发现VBA最适合处理与Excel密切相关的任务(了解MS Office)对象模型。我说的是,即使我在过去4年中写过几乎零行的VBA代码。我确实理解你正在使用webservices和其他依赖项,但我会说,如果你有良好的进展并且加载项按预期工作,我不会把自己投入一个全新的开发世界(VSTO& C#)只是为了变得冷静,你将不会获得太多的价值,特别是如果你知道

  • deploying managed code更难以将您的加载项复制到 文件夹,设置注册表,完成
  • 使用托管代码进行故障排除会更加困难,基本上您将需要记录更多内容并尝试重现可能不会在您的环境中发生但在客户端中发生的问题
  • 管理代码的重新设计并不是那么难,所以如果人们真的想窃取您的代码,除非您使用obfuscation
  • ,否则他们可以这样做
  • 以及最后也可能是最重要的,因为我知道在VSTO中没有简单的方法来做UDF

我对VB6 / COM自动化的经验很少,所以我很想听听之前做过类似事情的人的意见

回复:VSTO& UDF,在我的工作中,我们有一个VSTO加载项,以某种方式处理大型项目的UDF。我不是应用程序的主要开发人员,但我相信我们在那里使用Excel DNA所以请检查它以进一步探索托管代码选项

希望有所帮助

答案 1 :(得分:0)

我会看一下Excel DNA:https://github.com/Excel-DNA

我在开发与ASP.Net Web API通信的VBA加载项时遇到了类似的问题。无法真正在VBA中提供所有代码,因此我们需要一种给出编译代码的方法。连接到Web服务的速度非常快,这使得使用具有多个API调用的大量电子表格的用户更加困难。

您可以使用VB轻松地在可视化工作室中开发它们,因此可以复制和粘贴许多代码,然后稍微更改以适应您正在使用的VB的更高版本。

加载项编译为.xll 64位和32位版本。

我们处理功能区中所有登录和API的连接:https://exceldna.codeplex.com/wikipage?title=Ribbon%20Customization&referringTitle=Documentation

您可以使用更新用户友好的VB表单。

连接到其他.dll文件,以便跨多个加载项共享逻辑。

我们使用的调用API的UDF都可以异步运行释放Excel主线程。 https://exceldna.codeplex.com/wikipage?title=Asynchronous%20Functions&referringTitle=Documentation

它可以通过排队作为宏来运行任何VBA特定或CAPI代码。

几乎可以做你在VBA中可以做的所有事情。

Govert开发者https://stackoverflow.com/users/44264/govert在StackOverflow和论坛上非常活跃。他在开发过程中帮助了我们。 Excel DNA仍在更新和处理中。

如果您想了解更多细节,请与我们联系。