Automating Microsoft Word from a desktop or server process introduces deployment, security, memory usage, performance, and licensing concerns. A managed document processing component largely avoids those problems, which is described in detail in this article.

NOV Rich Text Editor implements a managed text-processing stack and a document object model for DOCX, RTF, HTML, PDF, and other formats. Applications work with document elements instead of controlling an external Word process.

MS Word automation relies on a technology from the 90s called COM, which stands for Component Object Model. It lays the foundations for a Microsoft technology used extensively in its Office line of products called OLE (Object Linking and Embedding). At a very basic level, COM defines how objects can communicate with each other by using interfaces and how an application can create a COM object by knowing its unique number called CLSID. To request functionality from this object, it must then query the newly created object for an interface it understands by asking it to provide a pointer to it given an interface ID called IID (Interface ID). Both the CLSID and IID are GUID numbers, which ensure that users will never use two coinciding IDs.

When the caller receives this pointer, it must call its AddRef() method, call methods on the interface, and, when done with it, manually release it using Release().

OLE builds on COM by defining standard interfaces and infrastructure for compound documents, linking and embedding, and OLE Automation, which is a subset of the OLE technology allowing calls to an object without knowing its specific interface. The services provided by OLE Automation are like modern C# reflection - you can query the methods and properties exposed by the object at runtime without knowing any interface IID exposed by the object. OLE Automation was the technology behind Visual Basic and this is how MS Word was automated back in the days of VB and still is in more modern times (using Microsoft Word Object Library) for .NET, for example.

Now that we've covered the basics of COM and OLE, let's take a look at why this approach poses the above-mentioned problems and how a managed text processing component such as NOV Rich Text Editor for .NET solves them.

The first obvious problem is deployment - when you request that the operating system create a COM object, it performs a lookup through the locally installed COM objects and if it finds an object with the specified ID, it will create this object and return the requested interface to it.

This requires MS Word to be installed on the machine where the request is performed, which imposes deployment problems as developers cannot bundle the MS Word installation with their own installer. MS Word can technically be automated using DCOM (Distributed COM) so it can rely on a separate machine inside the network but this imposes a lot of other problems related to configuration, network access, etc. Also, installing Office on any machine involves a lot of registry modifications and must be performed from an account with sufficient privileges, which can create a load on the sys-admin of the network and can be very problematic when dealing with large farms or software that has many distributions (think end-user commercial desktop software).

On the other hand, using a managed text processing component such as NOV Rich Text Editor for .NET does not have any of those deployment problems. All you have to do is to add the Nevron Open Vision NuGet package to the app's VS project. Then it will be distributed automatically along with your code. There are zero deployment considerations, registry modifications, and security concerns.

Another aspect of Word automation is the problem that is imposed on security. To create a COM object, the requesting process must perform a lookup in the registry and then run a separate process, because the Word COM object is created as an out-of-process COM executable (WINWORD.EXE). This means that the application or service that automates Word can potentially perform operations that are not directly granted to it by using the privileges assigned to Word for file access, for example. The list of security issues is very long and includes DoS attacks, impersonation, and others.

Much like with the deployment problems, a .NET component running inside the process of the called application or service can create, edit, and save DOCX or RTF files without any of the aforementioned security risks.

COM objects rely on the caller to explicitly manage their lifetime using a mechanism called reference counting using the AddRef/Release methods of the base COM IUnknown interface. This means that the COM object or interface maintains a counter that tracks how many callers are attached to it. Once the reference count drops to zero, the object must free its memory and optionally shut down the process it runs in, in the case of an out-of-process COM server, as is the case with Word. This poses memory usage problems because it can potentially cause memory leaks (the caller forgets to release the object and it stays indefinitely in memory). According to Microsoft, Word is primarily written in C++, which is a language with inherent memory problems due to deterministic memory management (think leaks), usage of direct unchecked memory access (think stack overwrite, memory corruption) and the like.

Using a fully managed .NET component to perform document creation does not pose those memory problems. Managed code can, of course, produce memory leaks, but .NET components do not, in general, suffer from reference counting and different forms of memory corruption.

As already mentioned, Word automation creates a separate background process. To communicate with this process, COM uses a process called marshalling which basically packages calls from the caller process and transfers them to the Word process using Windows RPC. To the caller, this looks like a normal function call but is much more computationally expensive. Then there is a managed-to-native boundary that is involved when calling the unmanaged COM proxy which also involves marshalling. Overall, marshalling can be a potential bottleneck for automatic document generation services that need to process large numbers of documents - for example a large company generating and sending personalized invoices to customers or customer notification emails.

In contrast, when using a .NET component running inside the process from managed code, those calls do not have to be marshalled, leading to performance gains which may be difficult or impossible to achieve when using Word with COM automation.

Last but not least, there is the licensing issue. In general, MS Word is licensed per computer so you cannot freely distribute an app or web service that automates it without first covering the per-computer licensing costs. In effect, this is similar to royalty fees.
NOV Rich Text Editor for .NET is royalty-free for desktop app redistribution, so you don't have to worry about costs when redistributing the application to a large number of customers or internal company users of the software.

Founded in 1998, Nevron Software is a component vendor specializing in the development of premium presentation layer solutions for .NET-based technologies. Today, Nevron has established itself as a trusted partner worldwide for .NET LOB applications, SharePoint portals, and reporting solutions. Nevron technology is used by many Fortune 500 companies, large financial institutions, global IT consultancies, academic institutions, governments, and non-profits.
For more information, visit: www.nevron.com.