Getting a Object Reference error in prod only when trying to use the Word DocumentClass

Question

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;

Halfway

Probable explanation: Word is not installed on the server? – Tuscan

Yes, Word is definitely installed on the server. I ran into a different problem earlier and found I needed it installed so it is there. In fact, I had to change permissions on Microsoft Word in DCOM in the Coomponent Services to get past an access denied error. – Halfway

Answer 1

1. Click Start, click Programs, click Administrative Tools, click Component Services.
2. Expand Component Services, expand Computers, expand My Computer, expand DCOM Config, and right-click Microsoft Word 97 - 2003 Document. Select Properties.
3. Click General. Set Authentication Level to Connect (None also work).
4. Click Identity. Set This user. Specify a user account that will always be used to run the COM application regardless of which user is accessing it.
5. Click button Apply.
6. Click button OK.

For more information on “Configuring DCOM for Remote Access" visit Configuring DCOM for Remote Access

Epanaphora

In case you cant find the "Microsoft Word 97 - 2003 Document" in Component Services, you might be viewing it in 64-bit mode. Here is a way to open it in 32-bit mode. forums.asp.net/t/… – Bridegroom

Answer 2

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

Hola

Is the Microsoft.Office.Interop Assembly permissions anywhere but in the Component Services? This is my first attempt at getting print merging running in an asp.net page so I am flying blind right now. – Halfway

Answer 3

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.)

Hollow

Word would be unable to open the document and thus Word.Documents.Open() would return null. (I ran into this myself though I'm not 100% sure if it was a NullReferenceException that I encountered. Whatever it was, the source of the problem was not obvious.) – Hollow

If you will update your answer to include that information, I'll be able to remove the downvote. – Revengeful

Answer 4

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.

Revengeful

I am confused by the comment above that my program does not work locally in debug mode. I click the button and the code runs, the word doc opens and merges the data and the document is displayed correctly so it works and I am in debug, please explain. – Halfway

@RJ: when you click the button and the code runs, the word document opens, etc., you have performed a set of code paths which work. You have done this by not testing all of the code paths that don't work. – Revengeful

This is a controlled environment with only a few users who all have Office 2007 installed on their workstations so I am not violating licensing. However, that is a good point you make and something that has to be considered. I agree with your statement about licensing. Good point! – Halfway

@RJ: Licensing is the smallest issue, and the easiest to solve. Your application is fundamentally broken and will never be fixed until you stop calling these APIs from ASP.NET. – Revengeful

John: As I said above, this is my first attempt at doing this. My other thought was to do a windows app and do a one-click deployment to the user workstations. Perhaps you can give me some guidance if you have done something like this before. My goal is to have an app that uses some sort of a template to print letters, forms, etc.. using merged data. What would you do in this case? Perhaps I should post another question about this. – Halfway

@RJ: Yes, post another question and reference this one. You don't want to do this with ASP.NET. – Revengeful

@John Saunders: It was a pretty good answer until I got to the licensing supposition. It's probably a better idea to direct someone to a Licencing Specialist in SMSP or EPG/CS/PS before putting a EULA scare into them for no apparent reason. On the "pretty good" part above, note that while your advice is solid, I think what you mean to say is "generally unattended server-side automation" instead of "never, under any circumstances". (Just look at HPC Services for Excel on R2 - that is 100% unattended Excel running on the server). Not trying to be an arse here, just add some situational clarity. – Nylon

@Otaku: what? HPC Services is written by Microsoft. If they use the actual excel.exe through automation (which I doubt) then they presumably know how. The license issue is not a "scare". It's a summary, and I said "may be violating". – Revengeful

@John Saunders: Nevermind. You just want to be right on everything, so go ahead - now you're right. (-1 for a poor answer that is not correct both technically and legally) – Nylon

-1 for not providing the right solution and deviating the topic to a different direction thereby wasting the time.. – Deathless

@Xtreme: there is no right solution to using Office Interop in a server. The right solution is, "don't do that". – Revengeful

@RJ: It's important to note that Office Automation on the server is not recommended and even discouraged, but certainly not "off limits" in any way or some kind of breach of software licensing. Please ensure you view and implement, where applicable, the recommendations on support.microsoft.com/kb/257757. – Nylon

@Otaku: note the following from the article you referenced: "Besides the technical problems, you must also consider licensing issues. Current licensing guidelines prevent Office applications from being used on a server to service client requests, unless those clients themselves have licensed copies of Office. Using server-side Automation to provide Office functionality to unlicensed workstations is not covered by the End User License Agreement (EULA)." That's what I meant by "may be violating your license". – Revengeful

@John Saunders: There was no indication in the OP's question that the .aspx page is used in response to client requests. Maybe it is, but we don't know. From what I can read it merges data and creates a template (that maybe people will then download). The point is that we don't know. The article is extremely clear on the technical and legal considerations, as it has always been. Besides the fact that they may be violating a license is also the fact that they may not be in any violation at all. Referencing that KB should suffice for the OP to work it out. – Nylon