问题
我的问题是:C# 是否天生支持后期绑定 IDispatch?
假装我正在尝试自动化 Office,同时与客户安装的任何版本兼容。
在 .NET 世界中,如果您在安装 Office 2000 的情况下进行开发,那么从现在到结束,每个开发人员和每个客户都必须拥有 Office 2000。
在 .NET 之前的世界中,我们使用COM与 Office 应用程序通信。
例如:
1) 使用与版本无关的 ProgID
"Excel.Application"
解决为:
clsid = {00024500-0000-0000-C000-000000000046}
然后使用 COM,我们要求将这些类之一实例化为一个对象:
IUnknown unk;
CoCreateInstance(
clsid,
null,
CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER,
IUnknown,
out unk);
现在我们要参加比赛了——能够在我的应用程序中使用 Excel。当然,如果真的要使用对象,就得调用有某种调用方式的方法。
我们可以得到各种接口声明,翻译成我们的语言。这种技术很好,因为我们得到
- 早期绑定
- 代码洞察力
- 编译类型语法检查
一些示例代码可能是:
Application xl = (IExcelApplication)unk;
ExcelWorkbook workbook = xl.Workbooks.Add(template, lcid);
Worksheet worksheet = workbook.ActiveSheet;
但是使用接口有一个缺点:我们必须掌握各种接口声明,并翻译成我们的语言。而且我们被困在使用基于方法的调用中,必须指定所有参数,例如:
ExcelWorkbook workbook = xl.Workbooks.Add(template, lcid);
xl.Worksheets.Add(before, after, count, type, lcid);
事实证明,在现实世界中,它有一些我们愿意放弃的缺点:
- 早期绑定
- 代码洞察力
- 编译时语法检查
而是使用IDispatch后期绑定:
Variant xl = (IDispatch)unk;
Variant newWorksheet = xl.Worksheets.Add();
因为 Excel 自动化是为 VB 脚本设计的,所以可以省略很多参数,即使没有它们就不会出现重载。
注意:不要将我的 Excel 示例与我想使用 IDispatch 的原因混淆。并非每个 COM 对象都是 Excel。某些 COM 对象除了通过 IDispatch 之外没有其他支持。