Reputation: 11
I have deployed my web application (ASP.NET/C#) on the Server (Win 2003) to make it possible to merge word documents and open them.
Everything worked fine: a .doc ducment was added to the bottom of another .doc document (using Microsoft.Office.Interop.Word libraries) and then opened with the client MS Word.
Unfortunately in the weekend an automatic update has been done on the Server by another team and I do not know yet which kind of update was done (maybe an Office 2003 Update, but it might be even a Server patch).
Anyway after that I get the following Warning in the Event Viewer and the application hangs when it comes to use Microsoft.Office.Interop.Word libraries:
Detection of product '{90110409-6000-11D3-8CFE-0150048383C9}', feature 'OfficeUserData', component '{4A31E933-6F67-11D2-AAA2-00A0C90F57B0}' failed.
The resource 'HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\MS Access Database\' does not exist.
We do not even use MS Access, but SQL Server instead. What I fear is that registry keys have been changed and now the system does not work anymore as expected.
I set the "NETWORK SERVICE" user with privileges to access/launch word and it is the same user used also for the Default App Pool. We use IIS6, Windows Server 2003 e Word 2003.
Could suggest any approach of solution? (even if I know that without knowing which update has been done, it might be hard).
Thanks
Upvotes: 1
Views: 249
Reputation: 4879
You should be able to check under the Windows updates to see what updates were recently applied. Hopefully, you could roll them back until you find the culprit.
Paul's right. Deploying a solution using MSOffice apps on a server can be a +very+ dicey proposition. Be prepared, and make use of watchdog timers and code to enumerate and kill errant WINWORD.EXE processes when you think it might have dropped off the deep end. it's not elegant stuff, but it can be made to work.
As for 3'rd party tools, I've looked at A LOT of them. If you're building a doc from scratch, most are ok, though they have varying levels of implemented functionality. If you can work with DOCX files exclusively, the OpenDoc XML SDK works quite nicely and is free. But it sucks to actually manipulate existing documents.
If you're planning on using existing documents as templates, you're options become much more narrow. You can do it with the OpenXML SDK, but it's VERY difficult. Windward reports works, but can be $$$.
Most of the "Word Compatible" libraries for sale don't implement all the functionality you're likely to need.
You'll most likely find that using the Word Object Model API is the only route to give you the capability you'll need. But, as always YMMV.
Upvotes: 0
Reputation: 6358
Using and Office components (beit Office itself or the PIAs) on a server is to be avoided at all costs:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
Like many others, I am regularly confronted with this problem and there is no easy solution. Either dedicate a little server somewhere to do your Office stuff (and be prepared to reboot it regularly) or use a third-party product that doesn't reference the PIAs.
Sorry to be the bringer of bad tidings...
Upvotes: 1