Why Microsoft Office Automation is Not a Good Idea
Generally, all kind of business applications have to create documents: invoices, reports, quotations or similar business correspondences. Typically, developers author applications that enable end users to modify text and spreadsheets and to create print-ready documents that can be sent via e-mail (PDF), fax or my traditional mail. The majority of applications deploy Microsoft® Office to create such documents. But even Microsoft® does not recommend automating their end-user software…
Generally, all kind of business applications have to create documents: invoices, reports, quotations or similar business correspondences. Typically, developers author applications that enable end users to modify text and spreadsheets and to create print-ready documents that can be sent via e-mail (PDF), fax or my traditional mail.
The majority of applications deploy Microsoft® Office to create such documents. But even Microsoft® does not recommend automating their end-user software Microsoft® Office:
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.
MSDN, Considerations for server-side Automation of Office.
Potential problems and pitfalls when deploying Microsoft® Office:
- Interactivity with the Desktop
Microsoft® Office is an end-user application and such applications need to be made visible in order to work correctly. If an error occurs, an error message might be displayed, which requires user interaction.
- Scalability
Microsoft® Office is designed to provide functionality to a single client. It is not recommended to automate Microsoft® Office in server-side applications as it is not scalable.
- Stability
"Using Microsoft® Office as a service component on a network server may reduce the stability of that computer, and therefore may reduce the stability of your whole network."
- Security
"Microsoft® Office applications were never intended for server-side use. Therefore, Microsoft® Office applications do not take into consideration the security problems that distributed components face."
A much better way to integrate word processing is by using TX Text Control Server for ASP.NET (incl. Windows Forms), built from scratch for such scenarios.
With our partner GrapeCity, we founded the Document Automation Alliance. The idea is to provide developers a one-stop competence center to gain information on how to effectively automate Microsoft® Office documents without attempting to deploy Microsoft® Office.
Read more about this joint venture on our dedicated website:
http://www.document-automation.net
Or download our trial version and test our shipped ASP.NET samples today:
Related Posts
Create a Table of Contents in Windows Forms using C#
This article explains how to create a table of contents in Windows Forms using the ribbon or programmatically. Creating a table of contents is required to organize large documents.
Official TX Text Control .NET Sample Applications Are Now Hosted on GitHub
This article gives a quick overview of the new repositories, their structure and our plans for the future.
ASP.NETJavaScriptDocument Editor
Detect Toggle Button Changes Using a MutationObserver
This article shows how to detect changes of toggle buttons in the ribbon of the web editor using a MutationObserver. The state of a toggle button in the ribbon visualizes the state of a certain…
Two Ways to Restart Numbered Lists in TX Text Control
In TX Text Control, numbered lists are continued by default and need to be reset when required. There is more than one way if you want to restart numbered lists in a document. In this article, two…
Zoom Tricks: Disabling CTRL + MOUSE WHEEL and More
This article shows how to disable CTRL + MOUSE WHEEL, implement zooming with keyboard and reset the zoom factor to its default value.