我被委托在Excel中创建一个财务规划工具，需要用到一些定制的函数/宏。
我的第一反应是使用VBA。我以前已经用过它来驱动Excel（大约5年前）。但我开始思考，是否最好使用VSTO。
有没有人有使用这两种技术的经验，并可以列出优缺点，以便我评估哪种方法最好。
5个回答
8
我建议你在Excel的标准开发中继续使用VBA，并在此过程中学习.NET。使用.NET肯定是下一步，但它会使你的Excel开发变得更加困难。
此外，VSTO不支持创建自定义工作表函数（“UDFs”），因此您需要一个VBA前端或创建一个没有使用VSTO的托管COM插件来完成此操作。相比之下，VBA允许您轻松创建UDFs。
使用.NET有许多优点，主要涉及强类型、完整的面向对象编程能力和组织大型项目的能力。但是，当涉及到Excel处理.NET或VSTO时，VBA在部署方面具有巨大优势，这是非常复杂的。同时，VBA也是一种更容易学习和入门的语言。
总的来说，我建议您在日常开发中使用VBA，但是在一旁学习VB.NET或C#，以便您的编程技能可以在Excel领域之外得到提升。最终，您的.NET技能可能足够强大，以至于您会更喜欢使用它而不是VBA，但是那一天你必须变得非常擅长.NET。
（有关此问题的另一个类似观点，请参见在Visual Studio中开发Excel应用程序是否会失去宏记录的好处？。） 编辑：关于Andy的评论，下面是最新更新：
在你的情况下，你应该使用C#，但我强烈建议你在此过程中使用C# 4.0和Visual Studio 2010，这将极大地改善操作COM对象模型（如Excel）所需的语法。VS 2010目前处于beta 2阶段，RTM日期定于4月12日，所以我们快到了。
至于部署，考虑到您的经验，我认为您不会在安装程序或类似工具上遇到太多麻烦。Visual Studio Tools for Office（VSTO）非常适合两件事：
此外，VSTO不支持创建自定义工作表函数（“UDFs”），因此您需要一个VBA前端或创建一个没有使用VSTO的托管COM插件来完成此操作。相比之下，VBA允许您轻松创建UDFs。
使用.NET有许多优点，主要涉及强类型、完整的面向对象编程能力和组织大型项目的能力。但是，当涉及到Excel处理.NET或VSTO时，VBA在部署方面具有巨大优势，这是非常复杂的。同时，VBA也是一种更容易学习和入门的语言。
总的来说，我建议您在日常开发中使用VBA，但是在一旁学习VB.NET或C#，以便您的编程技能可以在Excel领域之外得到提升。最终，您的.NET技能可能足够强大，以至于您会更喜欢使用它而不是VBA，但是那一天你必须变得非常擅长.NET。
（有关此问题的另一个类似观点，请参见在Visual Studio中开发Excel应用程序是否会失去宏记录的好处？。） 编辑：关于Andy的评论，下面是最新更新：
好的，是的，你应该这么说！大多数像你这样的人都是VBA程序员，正在尝试进入.NET。所以我误解了。我正在寻找比较信息的问题，如部署、调试和UDFs。根据对这个问题的回答，我应该提到我的C#有5年以上的经验，而我的VBA技能（或者说缺乏技能）只有3或4次每十年。
在你的情况下，你应该使用C#，但我强烈建议你在此过程中使用C# 4.0和Visual Studio 2010，这将极大地改善操作COM对象模型（如Excel）所需的语法。VS 2010目前处于beta 2阶段，RTM日期定于4月12日，所以我们快到了。
至于部署，考虑到您的经验，我认为您不会在安装程序或类似工具上遇到太多麻烦。Visual Studio Tools for Office（VSTO）非常适合两件事：
- 通过拖放设计师为您的插件创建自定义功能区。如果没有拖放设计师，您必须提供 XML。如果问我，XML 很好，但是使用拖放设计师确实是一种梦幻般的体验。
- 在工作表上使用 .NET 控件。我不知道这是否是你计划做的一部分，但 VSTO 可以在工作表上使用 .NET 控件。对于 .NET 程序员来说，这是一个非常好的功能，因为这些控件看起来更加流畅，并专门设计为与 .NET 配合使用。
不幸的是，VSTO 仅适用于 Excel 2003 及以上版本，而且我认为您必须为 Excel 2003 和 Excel 2007 创建单独的插件。另一方面，使用未使用 VSTO 的托管 COM 插件可以轻松兼容 Excel 2000 及以上版本。最后，VSTO 不支持 UDF 的创建，因此，您必须要么创建托管自动化插件，要么利用调用您的 VSTO 函数的 VBA 前端。
总的来说，如果您可以限制自己在 Excel 2007 及以上版本中使用，则应选择 VSTO。如果您的需求是 Excel 2003 及以上版本，则应考虑 VSTO。如果您需要在 Excel 2000 及以上版本上运行，则应选择托管 COM 插件。
对于 UDF 支持，我会创建一个托管自动化插件，这适用于 Excel 2002 及以上版本。如果您需要在 Excel 2000 或更低版本上使用 UDF，则需要一个调用您的 .NET 程序集中 COM-visible 方法的 VBA 前端。
这是我看到的基本优缺点。如果您需要更多信息，请告诉我。
-- Mike
- Mike Rosenblum
3
干杯。我正在寻找有关部署、调试和UDF的比较信息。根据问题的回答，我应该提到我有5年以上的C#经验，而我的VBA技能（或缺乏技能）只在每十年出现3或4次。 - Andy
好的，明白了，我没意识到你有这么多的C#经验。我已经更新了我的答案。 - Mike Rosenblum
回应Mike关于部署的观点，你需要为2007和2010分别准备不同的VSTO - 可能还有2013。这需要多个项目来构建VSTO。如果为2003构建，则必须使用.NET 2.0，而其余版本则需要.NET 4。 - Dominic Zukiewicz
4
鉴于您熟悉C#，我建议您看一下Addin Express（需要付费）和Excel DNA（免费），以及VSTO。Addin Express有一个版本中立的PIA，可以简化部署，可以处理函数和命令，并且可以使用Automation和XLL接口（XLL比Automation快得多）。Excel DNA更加优化于XLL接口，但非常适合开发工作表函数。
免责声明：我与Addin Express或Excel DNA没有任何联系。
免责声明：我与Addin Express或Excel DNA没有任何联系。
- Charles Williams
2
我认为在Excel中使用VBA编码并没有本质上的问题。这样做的优点是可以在Excel进程空间中运行，并且VBA与Excel对象模型的交互非常简单。然而，您（和您的用户）需要将您的工具视为Excel插件。
如果您希望您的工具拥有与Excel不同的身份，则自动化是您的选择。它会稍微慢一些（因为您是“外部进程”），对象模型也略微不太干净，但您的工具将拥有自己的身份。
（请注意，如果您使用C＃并且有选择使用VS2010和C＃4，则有许多自动化增强功能值得升级。）
如果您希望您的工具拥有与Excel不同的身份，则自动化是您的选择。它会稍微慢一些（因为您是“外部进程”），对象模型也略微不太干净，但您的工具将拥有自己的身份。
（请注意，如果您使用C＃并且有选择使用VS2010和C＃4，则有许多自动化增强功能值得升级。）
- Tim Jarvis
2
FYI - 你可以用纯VBA编写插件并获得你想要的代码/数据分离效果。听起来你好像在说你不能用纯VBA编写插件，但我可能理解有误。 - oob
嗯，不是的，你误解了我的意思。实际上我非常明确地表示，“在使用VBA编码时，需要将你的工具作为Excel插件来考虑”。 - Tim Jarvis
1
这里有许多好答案，所以我会尝试提出一个还没有被提及的观点。我建议使用VBA。有很多原因，但对我来说，主要因素是：
- 不需要客户端安装任何指定版本的 .Net
然而，显然VBA并不是非常受保护的语言，所以如果你有想要隐藏的代码，最好使用 .Net。
- Gaijinhunter
0
SpreadsheetGear for .NET 允许您在.NET（WinForms、ASP.NET等）应用程序中添加与Excel兼容的电子表格组件，而无需使用COM互操作性带来的缺点（性能、易用性）。
如果您想了解更多关于 SpreadsheetGear Windows Forms 电子表格控件的信息，请点击这里。您还可以在这里查看实时的ASP.NET示例，并且如果您想自己试用，可以在这里下载免费试用版。
免责声明：我拥有SpreadsheetGear LLC。
- Joe Erickson
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接