仅当尝试使用 Word DocumentClass 时，才会在产品中出现对象引用错误
我正在编写一个程序，该程序使用 .dotx 模板并在 aspx 页面中合并数据。该程序在我的本地开发工作站上运行完美，但当我将其部署到测试 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;
I am writing a program that uses a .dotx template and does a merge of data in an aspx page. The program works perfect on my Dev workstation locally but when I deploy it to a test IIS server, it fails on the second line below giving me an Object Reference error.
I ran into problems earlier because the Word Com object was not on the IIS server so I loaded Word onto the server and set permission in DCom and got past that problem. But now I get this error on the line that starts with wRange = .....
As I said, the program works perfectly locally in debug mode.
Any ideas?
Microsoft.Office.Interop.Word.DocumentClass
System.NullReferenceException: Object reference not set to an instance of an object
lines of code:
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;
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
有关“配置 DCOM 以进行远程访问”的更多信息，请访问 配置 DCOM 以进行远程访问
For more information on “Configuring DCOM for Remote Access" visit Configuring DCOM for Remote Access
如果服务器上确实安装了 word，请检查运行 IIS 的用户帐户是否确实具有 Microsoft.Office.Interop 程序集的权限
If word is really installed on the server check if the User account where IIS is running under has actually permission on the Microsoft.Office.Interop Assembly
在目标计算机上安装 Office 后，请确保直接打开 Word 等应用程序之一，因为可能会出现更多激活许可证的提示。在您逐步执行此过程之前，API 将无法工作，并且生成的错误将无法清楚地表明问题到底是什么。
NullReferenceException 可能是由 Word 无法打开文档引起的，因此 Word.Documents.Open() 将返回 null。老实说，我不能 100% 确定这就是导致您问题的原因——正如我所说，这些错误不会清楚地告诉您问题是什么。 （我自己不久前也遇到过这种情况，虽然我知道 API 抛出了异常，但我不记得它是否与您所看到的相同。）
After installing Office on the target machine, make sure you open one of the apps like Word directly because there may be more prompts for activating the license. The API won't work until you step through this process and the errors generated will not be clear as to what the problem really is.
The NullReferenceException may thus be caused by Word being unable to open the document, thereby Word.Documents.Open() would return null. To be honest I am not 100% sure this is what is causing your problem -- As I stated, the errors will not clearly tell you what the problem is. (I ran into this scenario myself a while ago and though I know the API was throwing an exception I cannot remember if it is the same as what you're seeing.)
您的程序在调试模式下无法在本地运行。您根本没有使用任何错误。
在任何情况下，您都不应永远使用 ASP.NET 应用程序或任何其他服务器应用程序中的任何 Office Automation API。这些 API 被设计为对交互式桌面应用程序的调用。他们所做的许多假设不适用于服务器应用程序。
例如，桌面应用程序通过用户操作同步成为 Windows 消息队列中的消息。 ASP.NET 应用程序中没有 Windows 消息队列，因此对共享数据的访问不同步。您的测试可能根本不会导致多个线程同时运行。
对于给定 COM 组件的所有用户来说，可能存在仅一个副本中的数据。这在桌面应用程序中工作得很好，因为只有一个用户。您的 ASP.NET 应用程序有许多用户同时执行代码。另一个假设被违反了。
所有这些都会产生实际上无法修复的细微错误。它们只能四处移动，让你以为你已经解决了问题，直到你意识到还有一个问题。这个循环永远不会结束，也永远不会结束，因为您将无法解决实际问题：问题在于您正在使用服务器应用程序中的 Office Automation API。
解决这个问题，您将不会再出现此类错误。
PS：也有可能您可能违反了 Microsoft Word 许可证，除非您的 ASP.NET 应用程序的所有用户都拥有 Word 应用程序的许可证。
Your program does not work locally in debug mode. You simply haven't exercised any of the bugs.
You should never, under any circumstances, use any of the Office Automation APIs from an ASP.NET application or any other server application. These APIs are designed as calls to an interactive, desktop application. Many of the assumptions they make do not apply to server applications.
For instance, a desktop application is synchronized by user actions becoming messages in the Windows message queue. There is no Windows message queue in your ASP.NET application, so access to shared data is not synchronized. Your tests may simply never have caused multiple threads to run at the same time.
There may be data that exists in only a single copy for all users of a given COM component. This works fine in a desktop application, since there is only a single user. Your ASP.NET application has many users all executing code at the same time. Another assumption violated.
All of these things will produce subtle bugs which cannot actually be fixed. They can only be moved around, leaving you to think you've solved the problem, right up to the time you realize that there's one more problem. This cycle never ends and never can end, because you will not have solved the actual problem: the problem was that you were using an Office Automation API from a server application.
Fix that problem, and you'll have no more bugs of this kind.
P.S. It also just so happens that you may be violating your license for Microsoft Word, unless all of the users of your ASP.NET application have licenses for the Word application.