类型“Microsoft.Office.Interop.Word.ApplicationClass”未定义构造函数

asp.net 引用操作 Word 组件时,出现 类型“Microsoft.Office.Interop.Word.ApplicationClass”未定义构造函数 的错误

   Microsoft.Office.Interop.Word._Application appWord =new Microsoft.Office.Interop.Word.ApplicationClass();
            Microsoft.Office.Interop.Word._Document docFile = null;

 

类型"Microsoft.Office.Interop.Word.ApplicationClass"未定义构造函数
解决办法：解决方案资源管理器 -> 引用 -> "Microsoft.Office.Interop.Word" -> 右键选择属性 -> 嵌入互操作类型的值改为"false"即可。

就软件而言，互操作性——这条术语用来描述的是不同的程序（programs）借助于同一套交换格式（exchange formats）来交换数据，读写相同文件格式（file formats）以及采用相同协议（protocols）的能力。（互操作性的这种定义并‘没有’期望那种在不同处理器平台<processor platforms >之上执行相同二进制代码<binary code>的能力。）互操作性的缺乏可能是在程序设计期间对于标准化（standardization）缺乏重视的一种后果。实际上，在计算机世界（computing world）的那些并未基于标准的部分当中，互操作性也的确并非理所当然的事情。

根据国际标准ISO/IEC 2382-01 信息技术词表，基础术语（ISO/IEC 2382-01, Information Technology Vocabulary, Fundamental Terms），互操作性定义如下：“在几乎或几乎无须用户了解各种功能单元的独特特性的情况下，这些功能单元之间进行通讯、执行程序或者传输数据的能力”。以上两段是维基百科对“互操作性”的解释，让我们对“嵌入互操作类型”有了个基本的概念。

 

那就接着讲什么叫“嵌入互操作类型”，下面是摘自msdn杂志上的一段。可能会给我们一些启迪和认识。

嵌入 COM 互操作类型

这更像是 C# 编译器功能，而不像是 C# 语言功能，但您现在可以使用 COM 互操作程序集，而不要求该程序集在运行时必须存在。目的是减轻将 COM 互操作程序集与您的应用程序一起部署的负担。

当 COM 互操作在最初版本的 .NET Framework 中引入时，就确立了主互操作程序集 (PIA) 的概念。引入此概念，是为了解决在组件之间共享 COM 对象的难题。for instance：如果您有一些不同的互操作程序集，分别定义了一个 Excel Worksheet，则我们无法在组件之间共享这些 Worksheet，因为它们具有不同的 .NET 类型。PIA 通过只存在一次而解决了这个难题：所有客户端都使用它，因此 .NET 类型始终是匹配的。

尽管 PIA 在理论上是个好主意，但在实际部署中却被证明是个大麻烦，因为它只有一份，而有多个应用程序可能会尝试安装或卸载它。而由于 PIA 通常很大，事情更复杂了。Office 在默认 Office 安装方式中并未部署它们，用户只需通过使用 TLBIMP 来创建自己的互操作程序集，即可轻松绕过这一个程序集系统。

因此，现在为了扭转这种局面，发生了两件事：

对于两个结构相同且共享相同识别特征（名称、GUID 等）的 COM 互操作类型，运行时能够聪明地将其看作同一个 .NET 类型。C# 编译器利用这一点的方式是在编译时直接在您自己的程序集中重现互操作类型，因此不再要求在运行时存在该互操作程序集。

由于篇幅所限，我不得不省略一些详细信息，但即使不了解这些信息，您也应该能够毫无障碍的使用这个功能，就像动态功能一样。您通过将引用上的“嵌入式互操作类型”属性设置为 true，告诉编译器为您将互操作类型嵌入到 Visual Studio 中。

由于 C# 团队希望这种方法成为引用 COM 程序集的首选方法，因此在默认情况下，Visual Studio 会将添加到 C# 项目中的任何新互操作引用的此属性设置为 True。如果您使用命令行编译器 (csc.exe) 来编译您的代码，请使用 /L 开关，而不是 /R 开关，来嵌入您必须引用的互操作程序集中的互操作类型。