Last post Aug 05, 2009 03:45 AM by auser2009
Aug 03, 2009 10:54 AM|AUser2009|LINK
I hope this is an appropriate place for my first post!
I have an internal website (built in VS 2008 / .NET 3.5, with VB as the main language, and running off IIS7) which deals with order processing, job management etc. I would like to build in the functionality to automate the creation of documents in Microsoft
Word format (e.g. invoices and other documents where I would like to base the document on a template but pull in job-specific info from SQL Server 2008).
I am very familiar with automating the creation of Word docs from Windows Forms apps and in VBA, but have never attempted/considered this from an ASP.NET/server-based situation and am interested in thoughts as to what would be most practical/appropriate
from the point of view of programmability, licensing and performance. I think potential options include:
(1) Server-side creation of XML-based .docx files via the OpenXML SDK. This sounds fine for internal users since we have Office 2007 as standard, but some of these documents will need to go to suppliers who have older versions of Office and would see it
as a "barrier" to use the file converters.
(2) Server-side creation of binary .doc files using the Word interops for .NET. But as Office itself is not installed on the server, is this even possible from a development (and licensing) point of view? And would this be a performance hog?
(3) Using ASP.NET to "farm out" creation of the Word documents to a separate/asynchronous process on another machine where Office is installed, to reduce server processing. But my feeling is this would introduce significant complexity (including the need
to build a separate Windows Forms app or Windows Service) plus result in a potentially annoying time delay for the end-users (who will just want to click a button and then have their Word doc ready in seconds...)
I'm assuming I'm not the first person who's needed to do this but my Googling hasn't really given me the best understanding of what my options really are.
Aug 03, 2009 12:20 PM|atconway|LINK
This can be done with the Office Interop .dlls, but please read this from Microsoft to help you form your design decisions:
Considerations for server-side Automation of Office:
Aug 04, 2009 08:22 AM|AUser2009|LINK
Thanks a lot for that.
So it looks like even the "farming out to another process" wouldn't be advisable given Microsoft's guidelines about not automating Office apps from a non-interactive Windows Service... Which leads me to conclude that using the OpenXML SDK is the only viable
option, really. I'm not too keen on having to inform our suppliers about needing to install the conversion filters for non-2007 users -- even though it's pretty straightforward, it will still be seen as "a hassle", but equally I'm not inclined to start figuring
out how to build form fields and the like into RTF code/templates... Then again, getting familiar with the OpenXML techniques is going to be a bit of a learning curve in itself.
It seems odd that Office would only in the most recent version have started properly catering for the need to automate document creation and processing in an "unattended" manner!
If anyone else has any specific experiences with this (especially any key dos/don'ts/won't-works with the ASP.NET+OpenXML approach) that would be appreciated.
Aug 04, 2009 11:20 AM|atconway|LINK
By the way, here is a great OpenSource alternative to using Office automation called NPOI. It is on CodePlex at the following link:
Aug 05, 2009 03:45 AM|AUser2009|LINK
Many thanks, again very useful.
Looks great for working with Excel files (something I am also likely to need to do at some point), but for now the priority is Word documents, so I will look into the OpenXML SDK in detail for the time being.