来自控制台应用程序的 Microsoft Word COM 互操作 [英] Microsoft Word COM interop from console application

查看:27
本文介绍了来自控制台应用程序的 Microsoft Word COM 互操作的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个使用 Word COM 互操作的 .NET Core 3.1 控制台应用程序,除非它尝试创建 Microsoft.Office.Interop.Word.Application 对象时抛出异常:

System.Runtime.InteropServices.COMException (0x80070520):检索 CLSID 为 {000209FF-0000-0000-C000-000000000046} 的组件的 COM 类工厂由于以下错误而失败:8007052 指定会话不存在.它可能已经被终止.(0x80070520).在 System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean wrapExceptions, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& hasNoDefaultCtor)在 System.RuntimeType.CreateInstanceDefaultCtorSlow(Boolean publicOnly, Boolean wrapExceptions, Boolean fillCache)在 System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, Boolean wrapExceptions)在 System.Activator.CreateInstance(类型类型,Boolean nonPublic,Boolean wrapExceptions)在 System.Activator.CreateInstance(类型类型)

这是我使用的构造函数调用:

_app = 新应用{DisplayAlerts = WdAlertLevel.wdAlertsNone,可见 = 假,FileValidation = MsoFileValidationMode.msoFileValidationSkip,Caption = FOO"};

这是什么原因造成的?

解决方案

概述

对于 2020 年 12 月或之后偶然发现此问题的任何人:

我管理一个报告服务器"(实际上是 Windows 10 Pro 桌面安装),它依赖于通过 COM 互操作的 Excel 自动化.所有报告都是通过本机任务计划程序安排的,并且即使在未登录时也设置为运行(这被配置为使用域帐户).从 12 月的第 2 周左右开始,我们所有的 Excel 自动化功能都停止运行.我知道这是由环境变化引起的,因为我们的自动化代码在 6 个月内没有发生任何变化.最初,我认为这是 Windows 10 2004/20H2 的问题(因为这两个更新都是在 12 月的第一周应用的);然而,反复试验似乎同时指向上述 Windows 更新和 最新的 Office 2016 更新(2011 版).

我完成了上述链接问题中建议的故障排除以及搜索 System.Runtime.Remoting.RemotingServices.AllocateUninitializedObject检索组件的 COM 类工厂时出现的其他解决方案由于以下错误,CLSID {00024500-0000-0000-C000-000000000046} 失败:80070520.尝试的步骤包括注册表调整、修复 Office 安装以及确保没有 Windows 或 Office 的待处理更新.最初,重新安装 Office 似乎是解决方案,因为它解决了第一个问题(或至少更改了错误).经过更多的反复试验,我偶然发现了实际的解决方案,以及大概的原因.

问题

在安装 Windows 10 2004/20H2 和 Office 2016(2011 版)后,通过 Windows 任务计划程序安排的办公自动化将不会运行.

分辨率

在组件服务下>计算机 >我的电脑DCOM 配置,找到 Office Licensing COM Server 16 并右键单击它.启动属性窗口,然后转到安全选项卡.在访问权限标题下,单击自定义单选按钮旁边的编辑....确保从任务计划程序运行自动化的用户设置存在于组/用户列表中,并且被授予本地访问和远程访问.

注释 + 有用的链接

此问题的根本原因似乎是由于 Windows 功能更新Office 2016 版本 2011 更新导致 Office 许可服务器的 DCOM 配置权限丢失.>

以下链接没有让我找到解决方案,但有助于缩小问题范围:

I've got a .NET Core 3.1 console application that's using Word COM interop, except when it tries to create the Microsoft.Office.Interop.Word.Application object it throws an exception:

System.Runtime.InteropServices.COMException (0x80070520): Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 80070520 A specified logon session does not exist. It may already have been terminated. (0x80070520).
   at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean wrapExceptions, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& hasNoDefaultCtor)
   at System.RuntimeType.CreateInstanceDefaultCtorSlow(Boolean publicOnly, Boolean wrapExceptions, Boolean fillCache)
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, Boolean wrapExceptions)
   at System.Activator.CreateInstance(Type type, Boolean nonPublic, Boolean wrapExceptions)
   at System.Activator.CreateInstance(Type type)

This is the constructor call I'm using:

_app = new Application
{
    DisplayAlerts = WdAlertLevel.wdAlertsNone,
    Visible = false,
    FileValidation = MsoFileValidationMode.msoFileValidationSkip,
    Caption = "FOO"
};

What causes this?

解决方案

Overview

For anyone stumbling into this issue December 2020 or later:

I manage a reporting "server" (actually is a Windows 10 Pro desktop install) that relies on Excel automation via the COM interop. All of the reporting is scheduled via the native Task Scheduler and is set to run even when not signed in (this is configured to use a domain account). Beginning around the 2nd week of December, all of our Excel automation ceased functioning. I knew this was caused by an environment change, as none of our automation code has changed in over 6 months. Initially, I believed it to be a problem with Windows 10 2004/20H2 (as both updates had been applied the first week of December); however, trial and error seems to point to both the aforementioned Windows updates and the latest Office 2016 update (Version 2011).

I ran through the suggested troubleshooting in the linked questions above and other solutions that show up when searching for System.Runtime.Remoting.RemotingServices.AllocateUninitializedObject or Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80070520. Steps attempted included registry tweaks, repair installs of Office, and ensuring there were no pending updates for Windows or Office. Initially, re-installing Office seemed to be the fix, as it addressed the first problem (or changed the error, at least). After some more trial and error, I stumbled into the actual resolution, as well as the approximate cause.

Problem

Office automation scheduled via the Windows Task Scheduler will not run following installation of Windows 10 2004/20H2 and Office 2016 (Version 2011).

Resolution

Under Component Services > Computers > My Computer > DCOM Config, locate Office Licensing COM Server 16 and right-click on it. Launch the properties window, then go to the Security tab. Under the Access Permissions header, click on Edit... next to the Customize radio button. Ensure that the user setup to run the automation from the Task Scheduler is present in the group / user list and is granted both Local Access and Remote Access.

Notes + Helpful Links

The underlying cause of this issue appears to have been a loss of permissions in the DCOM Configuration for the Office licensing server due to either the Windows Feature update OR the Office 2016 Version 2011 update.

The following links did not get me to the solution, but were useful in narrowing down the issue:

这篇关于来自控制台应用程序的 Microsoft Word COM 互操作的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆