VBA是Visual Basic for Applications
VSTO是Visual Studio Tools for Office
目前公司想用Excel来实现报表功能,我本以为VSTO是VBA的替换品,在vs.net环境下,应该使用vsto来开发Excel．看了msdn中"将代码从 VBA 转换到 Visual Basic .NET"的文章，更误以为是一种替代趋势（文章收藏于http://www.cnblogs.com/cowbird/articles/20433.aspx）．不过后来我发现不是这样，VBA 6.0没有终结．
具体可以看下面一篇非常好的文章，文章名为＂比较 Microsoft Visual Basic for Applications 6.0 与 Microsoft Visual Studio Tools for the Microsoft Office System＂,推荐给大家（原文取于http://www.microsoft.com/china/msdn/library/office/office/odc_ofCOMpareVBA6andvsto.mspx）
鉴于这篇文章，我们后来还是决定使用VBA来开发EXCEL．
有三个vba的理由：
1 vba可以适应多种版本的office
2 vba可以不依赖.net framework
3 微软并没有抛弃它（至少还没有看出要消灭它的迹象）
另外对vsto部署还有两个疑惑
1 vsto是把Excel部署在服务器端，让客户去统一调用，那么我还没明白本来用vba在客户端动态创建的EXCEL报表，用vsto去实现，什么东西放到服务器端？
2 服务器端的Excel自身可以存盘么？
我不是很懂，欢迎大家指教
全文如下：
比较 Microsoft Visual Basic for Applications 6.0 与 Microsoft Visual Studio Tools for the Microsoft Office System
Allison Balter
InfoTechnology Partners, Inc.
适用于：
Microsoft? Visual Studio? Tools for the Microsoft Office System
Microsoft Visual Basic? for Applications 6.3
Microsoft Office Word 2003
Microsoft Office Excel 2003
摘要：创建 Microsoft Visual Studio Tools for the Microsoft Office System 项目还是创建 Microsoft Visual Basic for Applications 6.0 项目：哪个更适合作为解决方案呢？阅读本文后您将了解到这两种环境有何异同，以及最后如何协同工作。
本页内容
| 简介 | |
| 带有 .NET Framework 的 Visual Studio Tools for Office 与 VBA 之间的区别 | |
| 保护代码 | |
| 部署应用程序 | |
| VBA 6.0 的使命终结了吗？ | |
| 小结 |
简介
Microsoft? Visual Studio? Tools for the Microsoft Office System 是随 Microsoft Office System 提供的一项新技术，包括 Microsoft Office Access 2003 Developer Extensions。Visual Studio Tools for Office 使您可以使用 .NET 兼容的语言（例如 Microsoft Visual Basic? .NET 和 Microsoft Visual C#?）为基于 Microsoft Office Word 2003 和 Microsoft Office Excel 2003 的应用程序编写托管代码。您不仅可以使用这些语言编写 Word 和 Excel 中的代码，还能从 .NET Framework 提供的强大功能和较高的生产率中获得更多好处。这些好处包括：
| • | 访问 Visual Studio .NET IDE（交互式开发环境） |
| • | 访问 Visual Studio .NET 提供的多种调试工具 |
| • | 充分利用所有 .NET 对象模型（例如 ADO.NET） |
| • | 使用服务器资源管理器 |
| • | 通过 Microsoft Office System 访问 Microsoft .NET Framework 类的强大功能 |
| • | 为您创建的代码选择更高的安全性选项 |
| • | 实现完全面向对象的编程，从而可以编写出更有效的代码 |
| • | 可以在 Excel 和 Word 应用程序中嵌入 Microsoft Windows? 窗体，从而使窗体包含更丰富的控件（与 Microsoft Visual Basic for Applications [VBA] 相比） |
幸运的是，您不仅可以充分利用所有这些功能，还能保留对 Word 和 Excel 对象模型的完全访问。在 Visual Studio Tools for Office 环境中编程时，编写的是托管代码。编写托管代码时使用的是面向公共语言运行库的语言，例如 Visual Basic .NET、Visual C# 和 Managed Extensions for C++ 等。而在 Word 文档或 Excel 电子表格中编写代码时，编写的是非托管代码。
托管代码具有许多优点。与托管代码一起提供的公共语言运行库会对代码进行验证，从而避免执行非法操作，例如访问不属于它的内存。托管代码还允许您访问 Microsoft .NET Framework 及其基类库。
那么为什么还要使用非托管代码呢？选择继续编写非托管 (VBA) 代码有以下几个原因：
| • | 对于某些类型的应用程序来说，使用非托管代码更容易实现 Excel 或 Word 操作的自动化，并且需要的代码较少。其他一些 Office 程序由于不受 Visual Studio Tools for Office 支持，实现自动化则需要使用 VBA（除非采用常规的 COM Interop 技术）。 |
| • | 托管代码并不总是适合创建 COM 外接程序。 |
| • | 如果对现有 VBA 解决方案进行轻微改进，通常不需要重写 VBA 代码，因为它仍可以继续运行。 |
| • | 编写 VBA 代码不需要部署 .NET Framework，而且并非所有组织都具备使用 .NET Framework 的条件。 |
| • | VBA 在 Microsoft Office System 文档内创建嵌入式代码，这样代码可以与文档一起打包。而 Visual Studio Tools for Office 代码存储在文档或电子表格外部，因此要求对部署技术有更全面的了解。 |
使用 Visual Studio Tools for Office，不仅可以获得 Visual Studio .NET 和 .NET Framework 的强大功能和较高的生产率，还能获得 Word 和 Excel 的扩展性和编程能力。
带有 .NET Framework 的 Visual Studio Tools for Office 与 VBA 之间的区别
对于 Microsoft Office System 开发，在您评估是使用 VBA 项目、Visual Studio Tools for Office 项目还是同时使用两者时，了解它们之间的具体区别非常重要。表 1 对这两个项目进行了比较。
表 1：VBA 项目与 Visual Studio Tools for Office 项目的比较
| 用途 | VBA 项目 | Visual Studio Tools for Office 项目 |
| 持续的 Microsoft 支持 |
是 |
是 |
| 需要 Microsoft Office System |
否 |
是 |
| 集成开发环境 |
是 |
是 |
| 应用程序安全性 |
集成了 Microsoft Office System 的安全性功能 |
集成了 Microsoft Office System 和 .NET Framework 的某些安全性功能 |
| 安全性配置的难易程度 |
容易 |
可能很困难 |
| 需要更改用户的本地安全策略 |
否 |
是 |
| 需要大型编程框架以支持开发 |
否 |
是 |
| 需要部署 .NET Framework |
否 |
是 |
| 可以完全访问 Microsoft Office System 的对象模型 |
是 |
基本上可以（会有一些数据类型转换问题） |
| 语言支持 |
VBA（基于 Visual Basic 6.0） |
Visual Basic .NET 和 Microsoft Visual C# |
| 面向对象的编程环境 |
否 |
是 |
| 使用 Win32 API 的难度 |
高 |
低，可以通过 COM Interop 获得 Win32 API 的完全支持 |
| 是否对 Microsoft Office System 中的所有应用程序可用 |
是 |
否（仅对 Word 和 Excel 可用） |
| 是否可以使用 Web 服务 |
是（通过附件工具包） |
是（编译到 IDE 中） |
| Microsoft Windows SharePoint? Services 集成 |
是 |
是 |
| 掌握的难易程度 |
容易（特别是使用宏记录器时） |
算不上难，但需要了解 .NET Framework 的基础知识 |
| 代码与文档集成 |
是（只有一个部署模型） |
否（代码实际上是一个程序集，提供更多灵活的部署模型） |
| 部署支持（自动更新代码） |
否 |
是 |
| 支持 XML 操作 |
有限 |
广泛 |
| 自动与 Microsoft Office System 一起安装 |
是 |
否 |
| 需要 .NET 主 Interop 程序集 (PIA) |
否 |
是（但 Microsoft Office System 可以自动包含这些程序集） |
| 命名空间支持 |
否 |
是 |
| 完善程度 |
低 |
非常高 |
上表中的某些内容特别值得关注。首先，请注意这两种项目都可以获得持续的 Microsoft 支持。另外，VBA 项目可以存在于多个 Office 版本中，而 Visual Studio Tools for Office 项目仅在 Microsoft Office System 中受支持。
这两种环境的语言支持也有较大差异。VBA 项目支持基于 Microsoft Visual Basic 6.0 的 VBA 语言。Visual Studio Tools for Office 项目支持 Microsoft Visual Basic .NET 和 Microsoft Visual C# 语言。由于 Visual Studio Tools for Office 具有面向对象的特性，因此这两种环境之间的编程模式也有很大的不同。
两种环境之间的部署也差别很大。虽然本文最后也讨论了部署，但此处强调的是两种项目类型在部署上的核心区别。部署 Visual Studio Tools for Office 项目还要求在目标计算机上安装 .NET Framework。在 VBA 项目中，代码通常作为 Word 文档或 Excel 电子表格的一部分；而在 Visual Studio Tools for Office 项目中，代码则包含在该项目所生成的程序集中。Visual Studio Tools for Office 提供无接触部署 (NTD) 支持，因此您无需重新调用和重新部署文档即可更新文档代码。Visual Studio Tools for Office 不会自动随 Microsoft Office System 一起安装。使用 Visual Studio Tools for Office 创建的项目需要具有 .NET Framework 主 Interop 程序集 (PIA) 才能运行。在客户端计算机上首次运行 Visual Studio Tools for Office 项目时，会自动按需安装这些 PIA。所有这些加起来形成了一个比一般 VBA 应用程序稍微复杂但却更灵活、更强大的初始部署。
安全性也是 VBA 项目和 Visual Studio Tools for Office 项目之间区别较大的一个方面。Word 或 Excel 文档中运行的 Visual Studio Tools for Office 程序集充分利用了 .NET Framework 的安全性功能。这意味着生成其他应用程序所基于的坚实的安全性基础现在可用于 Office 解决方案中。为了确保能够利用此优点，您还需要对程序集、信任、安全策略以及 .NET Framework 的其他内容有更多的了解，不过这些努力是非常值得的。
此外，还需要注意以下几点。Web 服务集成编译到了 Visual Studio Tools for Office IDE 中，从而使您可以轻松地将 Web 服务并入 Visual Studio Tools for Office 项目。Visual Studio Tools for Office 项目提供了广泛的 XML 支持。当然，事实上这两种项目类型并不是互斥的。一个应用程序或解决方案可以同时包含 VBA 和 Visual Studio Tools for Office 这两种项目。但需要注意，当使用混合代码创建解决方案时，调试过程可能会有些麻烦，因为很难确定哪段代码出现了问题。另外，也无法保证能够按照预期的方式触发事件（VBA 或托管代码）。
保护代码
Visual Studio Tools for Office 本身没有添加安全性功能，但使用它时可以使用 .NET Framework 附带的安全性功能，以及 Microsoft Office System 项目中已有的安全性功能。您可以使用所有这些编译到 .NET Framework 中的安全性功能来控制是否允许运行应用程序。例如，管理员可以为从特定 Intranet 服务器上部署的所有代码授予 FullTrust 权限，使其可以在本地计算机上的 Word 或 Excel 中运行。如果用户从该位置接收到包含托管代码的文档或电子表格，代码的执行不会出现任何问题。如果用户从其他位置接收到包含托管代码的文档，虽然可以打开文档，但不会执行代码。
每个用户的计算机都有一组规则，指定允许执行哪些代码以及执行哪些操作。在执行代码之前，公共语言运行库会收集凭证。凭证基于代码的来源（服务器名称）以及程序集是否已签名。凭证会映射到特定策略，策略分为四种：计算机、用户、企业和主机。策略可以不包含任何代码组，也可以包含多个代码组。代码组会提供从凭证到权限集的映射。权限集包括一个或多个权限。权限是指执行某项操作的权利。公共语言运行库使用获得的凭证将程序集映射到代码组，然后代码组再将程序集映射到四个策略的交叉部分。此映射决定了代码是否可以执行，如果可以，可以执行哪些操作。
部署应用程序
您可以根据具体需求，将编译 Visual Studio Tools for Office 项目时创建的 DLL 放到以下三个位置中的一个位置：如果与代码关联的文档供单个计算机上的单个用户使用，则可以将代码与文档一起放到该用户的计算机上。如果与代码关联的文档供多个用户访问，则可以将代码存储在网络共享位置，使每个客户端计算机每次都可以访问到最新的代码。第三种选择就是将代码存储在企业 Intranet 或安全的 Internet 站点上。这三种选择各有利弊。
在第一种选择中，文档和程序集都存储在单个用户的计算机上。它的优点是，用户无需连接到网络或 Internet 即可使用您生成的解决方案。主要缺点是需要部署应用程序更新。
在第二种选择中，用户将文档存储在自己的计算机上，而将程序集存储在一个远程共享位置。这使每个用户都可以保留“数据”（本例中为 Word 或 Excel 文档）的一个专用副本，同时又能访问最新版本的程序集。最大的缺点是用户需要连接到网络或 Internet 才能使用应用程序。.NET Framework 提供了“无接触部署”功能，使您可以轻松地修改代码并将其部署到用户。修改代码后，可以将 DLL 重新部署到其原始位置。当用户下次打开 Word 或 Excel 文件时，计算机会在检测到 DLL 更新后自动将最新版本下载到用户的计算机上并运行最新版本。此过程不需要用户参与。
在第三种选择中，用户将文档和程序集都存储在远程网络共享位置。这使用户可以充分利用 Word 和 Excel 提供的文档协作功能，主要缺点是需要始终与网络保持连接。
VBA 6.0 的使命终结了吗？
下一版 Microsoft Office System 仍然会使用 VBA 6.0，如果不再使用 VBA，Microsoft 会提供迁移策略。VBA 6.0 中包含大量旧代码。很多情况下，可能没有必要重写现有的代码。但 .NET Framework 提供的显著优点和功能可能会使您重新考虑是否需要对某些解决方案进行改进。在 Microsoft Office System 中，没有对 VBA 6.0 进行语言方面的改进。
当然，对于初级开发人员来说，第一次使用 Visual Studio Tools for Office 时需要掌握太多东西。对于初学者来说，学习如何创建 Office 解决方案时，宏录制仍不失为一种好方法，而此功能只能在 VBA 中实现。初级开发人员仍然可以把部分开发精力放在 VBA 6.0 上，而具备一定经验的开发人员则可以在 Visual Studio Tools for Office 环境中将解决方案的一部分生成为托管代码。这两种技术不仅可以共存，还可以互为补充，在同一个解决方案中协同工作。
小结
Visual Studio Tools for Office 对 Microsoft Office System 开发来说无疑是一次革命性的飞跃。它使您不仅可以获得 .NET Framework 的强大功能和较高的生产率，还能获得 Microsoft Office System 的扩展性和编程能力。Visual Studio Tools for Office 使 Visual Studio .NET 开发人员可以生成基于 Microsoft Office System 的应用程序，同时又能继续使用熟悉的编程环境，充分利用 Web 服务可靠的安全性、易于部署的特性和支持功能。
在可预见的将来，VBA 6.0 和 Visual Studio Tools for Office 将通过某种形式实现共存。开发人员可以继续享受 VBA 和宏记录器为 Office 环境带来的快速应用程序开发的好处。随着 Visual Studio Tools for Office 和 Microsoft Office System 开发的不断成熟，.NET Framework 为 Office 环境带来的强大功能和优势也日益明显。鉴于上述原因，我们相信这两种技术的结合将指日可待。