在使用Word DocumentClass时,仅在生产环境中出现对象引用错误

7
我正在编写一个程序,使用.dotx模板并在aspx页面中合并数据。该程序在我的Dev工作站上本地完美运行,但是当我将其部署到测试IIS服务器时,在下面的第二行失败,并给我一个对象引用错误。
我之前遇到问题是因为Word Com对象不在IIS服务器上,所以我在服务器上加载了Word并在DCom中设置了权限,解决了那个问题。但现在我在以wRange = .....开头的行上收到此错误。
正如我所说,该程序在调试模式下在本地完美运行。
有任何想法吗?
Microsoft.Office.Interop.Word.DocumentClass

System.NullReferenceException: Object reference not set to an instance of an object

代码行数:

Document BaseDocument = oWord.Documents.Open(ref oTemplate, ref oMissing, ref oMissing, ref oMissing, ref oMissing, ref oMissing, ref oMissing, ref oMissing, ref oMissing, ref oMissing, ref oMissing, ref oMissing, ref oMissing, ref oMissing, ref oMissing, ref oMissing);

wRange = BaseDocument.Bookmarks.get_Item(ref endOfDoc).Range;

1
可能的解释:服务器上未安装Word? - Aliostad
1
是的,在服务器上肯定安装了Word。我之前遇到了一个不同的问题,发现需要安装它,所以它已经安装好了。事实上,我不得不在组件服务中的DCOM上更改Microsoft Word的权限,以解决访问被拒绝的错误。 - RJ.
4个回答

6
  1. 点击“开始”,点击“程序”,点击“管理工具”,点击“组件服务”。
  2. 展开“组件服务”,展开“计算机”,展开“我的电脑”,展开“DCOM配置”,右键单击Microsoft Word 97 - 2003 Document。选择属性。
  3. 点击“常规”。将认证级别设置为连接(无也可以)。
  4. 点击“标识”。设置此用户。指定一个用户帐户,无论哪个用户访问它,该帐户始终用于运行COM应用程序。
  5. 点击“应用”按钮。
  6. 点击“确定”按钮。

有关“配置DCOM以进行远程访问”的更多信息,请访问配置DCOM以进行远程访问


如果在组件服务中找不到“Microsoft Word 97-2003文档”,可能是因为您正在64位模式下查看它。以下是以32位模式打开它的方法。 https://forums.asp.net/t/1650716.aspx?Microsoft+word+document+is+missing+from+component+services - Vidhyardhi Gorrepati

0
安装Office后,请确保直接打开其中一个应用程序,如Word,因为可能会有更多的提示来激活许可证。在完成此过程之前,API将无法正常工作,并且生成的错误将不清楚问题的真正原因。
因此,NullReferenceException可能是由于Word无法打开文档而导致的,因此Word.Documents.Open()将返回null。老实说,我并不100%确定这是否是导致您问题的原因--正如我所说,错误不会清楚地告诉您问题所在。(我自己遇到了这种情况,虽然我知道API正在抛出异常,但我不记得它是否与您看到的相同。)

Word 无法打开文档,因此 Word.Documents.Open() 将返回 null。(我自己也遇到过这个问题,尽管我不确定我遇到的是 NullReferenceException。无论是什么,问题的根源都不明显。) - Keith
如果您更新答案并包含该信息,我就可以取消踩了。 - John Saunders

0

如果 Word 确实安装在服务器上,请检查 IIS 运行的用户帐户是否具有对 Microsoft.Office.Interop 组件的实际权限。


Microsoft.Office.Interop程序集除了在组件服务中还有其他权限吗?这是我第一次尝试在asp.net页面上运行打印合并,所以现在我还没有任何经验。 - RJ.

-3

你的程序在调试模式下本地无法运行,你只是没有发现任何错误。

无论什么情况下,你都不应该从ASP.NET应用程序或其他服务器应用程序中使用Office自动化API中的任何一个。这些API被设计为对交互式桌面应用程序的调用。它们做出的许多假设并不适用于服务器应用程序。

例如,桌面应用程序通过用户操作变成Windows消息队列中的消息来进行同步。在你的ASP.NET应用程序中没有Windows消息队列,因此对共享数据的访问没有进行同步。你的测试可能从未导致多个线程同时运行。

一个COM组件中可能存在仅为所有用户的单个副本所存在的数据。这在桌面应用程序中可以正常工作,因为只有一个用户。你的ASP.NET应用程序有许多用户同时执行代码。另一个被违反的假设。

所有这些事情都会产生微妙的错误,实际上无法修复。它们只能被转移,让你认为你已经解决了问题,直到你意识到还有一个问题。这个循环永远不会结束,也永远不可能结束,因为你没有解决实际问题:问题在于你正在从服务器应用程序中使用Office Automation API。
解决那个问题,你就不会再有这种错误了。

顺便提一下,如果您的ASP.NET应用程序的所有用户没有Word应用程序的许可证,那么您可能正在违反Microsoft Word的许可证。


这是一个受控环境,只有少数用户在他们的工作站上安装了Office 2007,因此我没有违反许可协议。然而,你提出的观点很好,这是必须考虑的事情。我同意你关于许可证的说法。好观点! - RJ.
@RJ:是的,请发布另一个问题并引用此问题。你不想使用ASP.NET来做这件事。 - John Saunders
@John Saunders:直到我看到许可证假设,这是一个相当不错的答案。在没有明显原因的情况下,最好将某人引导到SMSP或EPG/CS/PS中的许可证专家,而不是让他们因EULA而感到恐慌。关于上面的“相当不错”的部分,请注意,虽然您的建议很实用,但我认为您想说的是“通常不受监管的服务器端自动化”,而不是“在任何情况下都不会”。(只需查看R2上的Excel HPC服务-这是100%在服务器上运行的未经监管的Excel)。我并不是要表现得很刻薄,在此只是添加一些情境上的清晰度。 - Todd Main
@John Saunders:算了吧。你只是想在所有事情上都正确,那就继续吧 - 现在你是对的。(因为一个既不技术上正确也不合法的差劲答案而扣1分) - Todd Main
@Xtreme:在服务器上使用Office Interop没有正确的解决方案。正确的解决方案是“不要这样做”。 - John Saunders
显示剩余9条评论

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接