Microsoft Office Interop (Word Automation) in C# and VB.NET
Microsoft Office Interop Word is an option when creating or reading Word files (DOC, DOCX, RTF) from C# or VB.NET applications. However, it has many drawbacks in projects.
You may face issues when using Microsoft Office Interop (Word Automation) from C# or VB.NET, which we will discuss in this article.
Why Microsoft Office Interop is not the best option
These are the main downsides of using Word automation:
- Word automation requires a license for Microsoft Word on every client machine.
- It requires that all client machines have the same version of Microsoft Word installed.
- When using automation, Word is loaded in the background, taking a few MB, and loading many files and DLLs.
- Microsoft Word was designed as a UI application, and because of that, the API is very slow. Generating a simple document with 30 paragraphs takes 10.2 seconds on our test machine.
- Microsoft Word API is exposed as a COM object. This results in the same disadvantages as calling any COM object from the managed code (type conversions, need for a COM wrapper, poor integration with .NET Framework, etc.).
A better alternative to Word Automation
With Microsoft Office installed on most business desktops, it is tempting to use Microsoft Word Interop. But it offers several disadvantages that can harm your work and be a downturn in your productivity.
The following table lists the main downsides of using Word automation and the benefits of using GemBox.Document to avoid them. You can compare both methods' performance and requirements:
|Microsoft Word automation||GemBox.Document component|
|Requires a license for Microsoft Word on every client machine.||Requires only the developer using the component to have one GemBox.Document developer license, even if the developed application is installed on thousands of client machines.|
|Requires all client machines to have the same Microsoft Word version installed.||Files generated with GemBox.Document are compatible with Word 2007, Word 2010, Word 2013, OpenOffice, and LibreOffice, so any of these products can be installed on a client machine.|
|When using automation, Word is loaded in the background, taking a few MBs and loading many files and DLLs.||GemBox.Document is a single component taking around 2 MB. Additional memory is allocated only when needed to perform certain operations.|
|Microsoft Word was designed as a UI application, and because of that the API is very slow. Generating a simple document with 30 paragraphs takes 10.2 seconds on our test machine.||GemBox.Document is designed for processing large numbers of Word files. The same test took 0.12 seconds on our test machine (85 times faster than Microsoft Word).|
|Microsoft Word API is exposed as a COM object. This results in the same disadvantages as calling any COM object from the managed code (type conversions, need for a COM wrapper, poor integration with .NET Framework, etc.).||GemBox.Document is a pure .NET component, designed and developed to conform to Microsoft standards for .NET libraries.|
Why Choose GemBox.Document
When comparing and evaluating different products for manipulating documents in .NET, consider the following:
- Plan and fair licensing
- If the API is 100% managed code
Let's check each of the points you should consider.
Plain and fair licensing
When you purchase GemBox.Document there is no cost for additional servers, and you can use our component for an unlimited number of projects. This means you don't need to purchase additional "OEM licenses". Also, we don''t force you to purchase subscription packages.
Our licensing is very simple; every developer working with our component must have a license. It doesn't matter if it is a Windows or web application, how many servers you use, or if you have just one or millions of customers.
In the case of a desktop application, you don't want your users to wait 20 seconds for every single report. You want your server to simultaneously support as many users as possible for a web application. For comparison, on our test machine GemBox.Document needs 0.1 seconds to read and write a single DOCX file of 2 pages (30 paragraphs, 900 words with various formatting).
The performance example is included in theGemBox.Document Examples, so you are free to do the test yourself and see how our component performs with the data you require.
Clean and easy-to-use API
GemBox.Document is designed and developed to conform to Microsoft standards for .NET libraries. It also enables you to access document elements more easily—for example, the same task of adding a formatted paragraph with GemBox.Document looks like this:
var normalRun = new Run(doc, " This text is not bold."); var boldRun = new Run(doc, "This text is bold."); boldRun.CharacterFormat.Bold = true; section.Blocks.Add(new Paragraph(doc, boldRun, normalRun));
and like this with automation:
var para = doc.Content.Paragraphs.Add(ref oMissing); var boldText = "This text is bold."; para.Range.Text = boldText + " This text is not bold."; var range = para.Range; object unit = WdUnits.wdCharacter; object count = -(para.Range.Text.Length - boldText.Length); range.MoveEnd(ref unit, ref count); range.Bold = 1;
100% managed code
Some similar products (and Microsoft Word objects) are old COM components with .NET RCW (Runtime Callable Wrapper). This may bring many performance and interoperability disadvantages as every method call you make goes through the wrapper until it reaches C++ code.
On the other hand, our GemBox.Document component is 100% managed, written entirely in C#, and designed to support both Visual Basic .NET and C# equally.
In this article, you saw the differences between Word Automation and GemBox.Document.
You can continue exploring the GemBox.Document component to see all its functionalities.