Microsoft Office Interop (Word Automation) in C# and VB.NET

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:

Why Choose GemBox.Document

When comparing and evaluating different products for manipulating documents in .NET, consider the following:

• Plan and fair licensing
• Performance
• Usability
• 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.

Performance

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.