XLA、COM、自动化、托管代码插件
XLA vs COM vs Automation vs Managed-Code Add-in
我需要您的帮助来决定最佳策略和技术，以便继续开发成功的内部 VBA 应用程序。
在我们公司（一家基于网络的金融信息分发商），多年来，我们开发了一个 VBA XLA 插件应用程序，仅供我们公司内部使用，这有助于链接我们的财务信息数据库与 Excel 工作表，通过使用多个 UDF，由 ADO/SQL 和其他业务对象逻辑支持。这个应用程序成为我们可靠、快速和有用的工具，有点类似于旧的 DDE 链接，但比它更复杂和灵活。
最近我们用基于 SOAP 的 Web 服务和 XMLHTTP MSXML 6.0 技术替换了系统的 ADO/SQL 部分，从字面上将我们的数据库放入云中。目标是将应用程序转换为可以在我们公司外部使用的产品。这项工作已经完成，并且运行良好，具有所有功能、启动时加载、用户身份验证和会话控制 login/logout、与 EXCEL 的无缝集成、用户友好的消息，所有这些都在一个文件中完成2.036Kb XLA 加载项文件，跨越 15000 多行好的 VBA 代码。但是，我们觉得它还不能像现在这样分发...
我们认为，为了成功地将此应用程序作为产品发布给我们的客户，必须将此应用程序转换为编译代码而不是解释 VBA。有很多理由证明这样做是合理的，包括安全性、速度、稳健性等。但我们现在不需要深入探讨这些细节。
我们最初的想法是使用 VB6 和自动化设计器将我们的 VBA 代码快速转换为 VB6 自动化插件。除了 VB6 是旧技术这一事实外，自动化插件似乎不是理想的解决方案，因为我们的应用程序需要与 Excel 事件和最终用户进行一些交互，至少在 "login" 和 "logout" 到基于 Web 服务的数据库（以及一些其他需要通过表单进行用户交互的功能）中，但似乎自动化插件不适合除 UDF 之外的任何其他内容。在这里，我们想了解其他人在自动化插件和最终用户交互方面的经验。
因此，COM 加载项是下一个选项。同样，这些允许通过菜单按钮和命令进行交互，但不允许在工作表中使用 UDF。或者我们已经读过。此外，我们了解到 COM 插件可以作为自动化插件（毕竟允许 UDF），但它们将作为 Excel 环境中的两个独立实体（一个 COM 和一个插件） ), 一半不与另一半交流。这是我们不能接受的。同样，我们希望更多地了解其他人在这方面的经验。
然后是托管代码（.NET、Interop 和 VSTO）作为其他可行的选项。然而，虽然入门很简单，但不清楚 Interop 是否会留下来，也不清楚托管代码的最佳策略是什么。同样，我们想了解其他人在这个领域的经验。
因此，最后的问题是：根据我们的要求（即在启动时加载、通过基于 SOAP 的网络服务 (MSXML 6.0) 访问数据、UDF 的功能、login/logout 会话控制、用户友好错误处理等），事实上我们已经有 15.000 行好的 VBA 代码，这是我们继续开发这个 Excel 组件的最佳技术，以便将其变成易于安全分发的产品？非常欢迎这方面的所有评论和想法。
您项目的精彩总结。
我也很好奇其他人对 "right" 此类任务的解决方案有何看法。不过这不是一个容易的决定。
我的简短回答是 "stick with VBA"，除非您真的很担心从很棒的 VBA 插件窃取您的代码。
我选择 VBA 的原因是我使用 VSTO/COM 的时间越长，我发现 VBA 是处理任务的最佳选择与 Excel（了解 MS Office）对象模型密切相关。我是说在过去的 4 年里，即使我写了几乎零行的 VBA 代码。我确实知道您正在使用网络服务和其他依赖项，但我想说的是，如果您取得了良好的进展并且加载项按预期工作，我不会将自己投入到一个全新的开发世界（VSTO 和 C#）中很酷，你不会从中获得太多价值，特别是如果你知道
- deploying managed code 比将您的加载项复制到
文件夹，设置注册表，完成
- 使用托管代码进行故障排除是一种更困难的方式，基本上您将不得不记录更多并尝试重现可能不会在您的环境中发生但在客户端中发生的问题
- 重新设计托管代码并不难，所以如果人们真的想窃取您的代码，他们可以做到，除非您使用 obfuscation
- 最后一个对你来说可能也是最重要的 据我所知，在 VSTO 中做 UDF 没有简单的方法
我对 VB6/COM 自动化的经验很少，所以我很想听听以前做过类似事情的人的意见
回复：VSTO 和 UDF，在我的工作中，我们有一个 VSTO 加载项，它以某种方式处理大型项目的 UDF。我不是该应用程序的主要开发人员，但我相信我们在那里使用 Excel DNA 所以请检查它以进一步探索托管代码选项
希望对您有所帮助
我会看一下 Excel DNA：https://github.com/Excel-DNA
我在开发一个与 ASP.Net Web API 通信的 VB 插件时遇到了非常相似的问题。无法真正给出 VBA 中的所有代码，因此我们需要一种给出编译代码的方法。连接到 Web 服务会冻结 excel，这让用户更难处理具有多个 API 调用的大量电子表格。
您可以使用 VB 在 visual studio 中轻松开发它们，因此可以复制和粘贴大量代码，然后稍作更改以适应您正在使用的 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 the Developer https://whosebug.com/users/44264/govert 在 Whosebug 和论坛上非常活跃。他帮助我们完成了开发工作。 Excel DNA 仍在更新和研究中。
如果您需要更多详细信息，请告诉我。
我需要您的帮助来决定最佳策略和技术，以便继续开发成功的内部 VBA 应用程序。
在我们公司（一家基于网络的金融信息分发商），多年来，我们开发了一个 VBA XLA 插件应用程序，仅供我们公司内部使用，这有助于链接我们的财务信息数据库与 Excel 工作表，通过使用多个 UDF，由 ADO/SQL 和其他业务对象逻辑支持。这个应用程序成为我们可靠、快速和有用的工具，有点类似于旧的 DDE 链接，但比它更复杂和灵活。
最近我们用基于 SOAP 的 Web 服务和 XMLHTTP MSXML 6.0 技术替换了系统的 ADO/SQL 部分，从字面上将我们的数据库放入云中。目标是将应用程序转换为可以在我们公司外部使用的产品。这项工作已经完成，并且运行良好，具有所有功能、启动时加载、用户身份验证和会话控制 login/logout、与 EXCEL 的无缝集成、用户友好的消息，所有这些都在一个文件中完成2.036Kb XLA 加载项文件，跨越 15000 多行好的 VBA 代码。但是，我们觉得它还不能像现在这样分发...
我们认为，为了成功地将此应用程序作为产品发布给我们的客户，必须将此应用程序转换为编译代码而不是解释 VBA。有很多理由证明这样做是合理的，包括安全性、速度、稳健性等。但我们现在不需要深入探讨这些细节。
我们最初的想法是使用 VB6 和自动化设计器将我们的 VBA 代码快速转换为 VB6 自动化插件。除了 VB6 是旧技术这一事实外，自动化插件似乎不是理想的解决方案，因为我们的应用程序需要与 Excel 事件和最终用户进行一些交互，至少在 "login" 和 "logout" 到基于 Web 服务的数据库（以及一些其他需要通过表单进行用户交互的功能）中，但似乎自动化插件不适合除 UDF 之外的任何其他内容。在这里，我们想了解其他人在自动化插件和最终用户交互方面的经验。
因此，COM 加载项是下一个选项。同样，这些允许通过菜单按钮和命令进行交互，但不允许在工作表中使用 UDF。或者我们已经读过。此外，我们了解到 COM 插件可以作为自动化插件（毕竟允许 UDF），但它们将作为 Excel 环境中的两个独立实体（一个 COM 和一个插件） ), 一半不与另一半交流。这是我们不能接受的。同样，我们希望更多地了解其他人在这方面的经验。
然后是托管代码（.NET、Interop 和 VSTO）作为其他可行的选项。然而，虽然入门很简单，但不清楚 Interop 是否会留下来，也不清楚托管代码的最佳策略是什么。同样，我们想了解其他人在这个领域的经验。
因此，最后的问题是：根据我们的要求（即在启动时加载、通过基于 SOAP 的网络服务 (MSXML 6.0) 访问数据、UDF 的功能、login/logout 会话控制、用户友好错误处理等），事实上我们已经有 15.000 行好的 VBA 代码，这是我们继续开发这个 Excel 组件的最佳技术，以便将其变成易于安全分发的产品？非常欢迎这方面的所有评论和想法。
您项目的精彩总结。
我也很好奇其他人对 "right" 此类任务的解决方案有何看法。不过这不是一个容易的决定。
我的简短回答是 "stick with VBA"，除非您真的很担心从很棒的 VBA 插件窃取您的代码。
我选择 VBA 的原因是我使用 VSTO/COM 的时间越长，我发现 VBA 是处理任务的最佳选择与 Excel（了解 MS Office）对象模型密切相关。我是说在过去的 4 年里，即使我写了几乎零行的 VBA 代码。我确实知道您正在使用网络服务和其他依赖项，但我想说的是，如果您取得了良好的进展并且加载项按预期工作，我不会将自己投入到一个全新的开发世界（VSTO 和 C#）中很酷，你不会从中获得太多价值，特别是如果你知道
- deploying managed code 比将您的加载项复制到 文件夹，设置注册表，完成
- 使用托管代码进行故障排除是一种更困难的方式，基本上您将不得不记录更多并尝试重现可能不会在您的环境中发生但在客户端中发生的问题
- 重新设计托管代码并不难，所以如果人们真的想窃取您的代码，他们可以做到，除非您使用 obfuscation
- 最后一个对你来说可能也是最重要的 据我所知，在 VSTO 中做 UDF 没有简单的方法
我对 VB6/COM 自动化的经验很少，所以我很想听听以前做过类似事情的人的意见
回复：VSTO 和 UDF，在我的工作中，我们有一个 VSTO 加载项，它以某种方式处理大型项目的 UDF。我不是该应用程序的主要开发人员，但我相信我们在那里使用 Excel DNA 所以请检查它以进一步探索托管代码选项
希望对您有所帮助
我会看一下 Excel DNA：https://github.com/Excel-DNA
我在开发一个与 ASP.Net Web API 通信的 VB 插件时遇到了非常相似的问题。无法真正给出 VBA 中的所有代码，因此我们需要一种给出编译代码的方法。连接到 Web 服务会冻结 excel，这让用户更难处理具有多个 API 调用的大量电子表格。
您可以使用 VB 在 visual studio 中轻松开发它们，因此可以复制和粘贴大量代码，然后稍作更改以适应您正在使用的 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 the Developer https://whosebug.com/users/44264/govert 在 Whosebug 和论坛上非常活跃。他帮助我们完成了开发工作。 Excel DNA 仍在更新和研究中。
如果您需要更多详细信息，请告诉我。