使用VBA和.Net自动化Excel的优点和缺点
我一直负责在Excel中创build一个财务计划工具，这将从一些自定义函数/macros中受益。
我最初的反应是使用VBA。 我以前用它来驱动Excel（比如5年前）。 但是，我开始怀疑，如果我使用VSTO会更好。
有没有人有使用这两种技术的经验，可以列出优点和缺点，以便我可以评估哪个课程是最好的。
我build议你坚持使用Excel进行标准开发的VBA，并在这方面学习.NET。 使用.NET绝对是下一步，但它使得你的Excel开发更加困难。
此外，VSTO不会创build用户定义的工作表函数（“UDF”），所以您需要一个VBA前端，或者创build一个托pipe的COM插件，而不使用VSTO，以便执行此操作。 相比之下，VBA使您可以毫不费力地创buildUDF。
使用.NET有许多优点，主要是关于强types，全面的OOPfunction以及组织大型项目的能力。 但是在涉及到部署时，VBA与.NET相比具有巨大的优势，而在处理.NET或VSTO时，这对于Excel来说相当复杂。 VBA也是一种更容易学习和使用的语言。
总的来说，我build议你在日常开发中使用VBA，但是要学习VB.NET或C＃，这样你的编程技能才能在Excel领域以外发展。 最终，你的.NET技能可以变得足够强大，以至于你更愿意使用它来通过VBA，但是你将不得不在.NET中变得相当不错。
（对于另一个类似的观点， 如果我在Visual Studio中开发Excel应用程序 ，请参阅我是否失去了macros录制的好处？ ）
编辑：更新关于安迪的评论，下面：
像部署，debugging和UDF的问题是我正在寻找比较信息。 根据对这个问题的回答，我应该提到我有5年以上的C＃经验，而我的VBA技能（或缺乏）只有十年三四次
好的，是的，你应该说！ 像这样的问题的大多数人是想要进入.NET的VBA程序员。 所以我误解了
在你的情况下，你应该使用C＃，但是我强烈build议在Visual Studio 2010上使用C＃4.0，这将大大改善对象COM对象模型（如Excel）操作所需的语法。 VS 2010目前处于testing版2，RTMdate定于4月12日，所以我们几乎在那里。
至于部署，根据你的经验，我认为你不会有太多的安装包或类似的东西，而Visual Studio Tools for Office（VSTO）对于两件事情来说是非常好的：
-
通过拖放devise器为您的加载项创build自定义function区排列。 如果没有拖放devise器，则必须提供XML。 如果你问我的话，XML就好了，但是拖放devise师确实是一个梦想
-
在工作表上使用.NET控件。 我不知道这是否是你计划做的一部分，但是VSTO可以在工作表上使用.NET控件。 对于一个.NET程序员来说，这是一个非常好的function，因为这些控件看起来更加stream畅，并且专门devise用于.NET。
不幸的是，VSTO仅适用于Excel 2003及更高版本，我认为您必须为Excel 2003和Excel 2007创build单独的加载项。另一方面，不使用VSTO而创build的受pipe理COM加载项可以与Excel兼容2000以上，没有任何困难。 最后，VSTO不支持创buildUDF，因此，您必须为其创build托pipe自动化插件，或者使用调用VSTO函数的VBA前端。
总的来说，如果你能限制自己到Excel 2007及以上版本，我会selectVSTO。 如果您的要求适用于Excel 2003及更高版本，我会考虑VSTO。 如果你需要能够在Excel 2000及以上版本上运行的话，我会使用托pipe的COM加载项。
对于UDF支持，我将创build一个托pipe的自动化插件，这对Excel 2002及更高版本来说是可行的。 如果您需要在Excel 2000或更低版本上使用UDF，那么您将需要一个在.NET程序集中调用COM-visible方法的VBA前端。
正如我所看到的那样，这些是基本的赞成和反对。 让我知道如果你需要知道更多。
迈克
鉴于您对C＃的熟悉程度，我build议您查看Addin Express（费用）和Excel DNA（免费），以及VSTO。 Addin Express具有版本中立的PIA，它简化了部署，可以处理函数和命令，并且可以使用自动化和XLL接口（XLL比自动化要快得多）。 Excel DNA针对XLL界面进行了更多优化，但对于开发工作表function非常有用。
免责声明：我与Addin Express或Excel DNA没有任何关系
我不认为在Excel中的VBA中编码这个问题本质上是错误的。 它具有在excel的进程空间中运行的优点，并且与Excels对象模型的VBA交互非常简单。 但是，您（和您的用户）需要真正将您的工具视为Excel加载项。
如果你想让你的工具拥有一个独立于Excel的标识，那么自动化是你的select。 这是一个慢一点（你是“过程中”），对象模型是less许干净，但你的工具将拥有自己的身份。
（注意，如果你使用C＃，并且如果你有select使用VS2010和C＃4，那么有一系列值得升级的自动化增强function）
用于.NET的SpreadsheetGear允许您将.NET兼容的电子表格组件添加到您的.NET（WinForms，ASP.NET等）应用程序中，而没有COM Interop的缺点（性能，易用性）。
您可以在这里了解更多有关SpreadsheetGear Windows Forms电子表格控件的信息 ，请参阅此处的实时ASP.NET示例，并在此处下载免费试用版，如果您想自行试用。
免责声明：我自己的SpreadsheetGear LLC
这里有很多很好的答案，所以我会试着提出一个尚未完成的观点。 我会坚持使用VBA。 有很多原因，但对我来说主要因素是：
- 不要求客户端有任何指定的版本。 的.Net安装
但是，VBA显然不是很受保护，所以如果你有隐藏的代码，最好用.Net来处理。