Office interop (server-side automation)
Definition
Driving Microsoft Office from code to open or convert documents. It works on a desktop and is explicitly discouraged on a server, by Microsoft as well as by everyone who has tried it.
Office was built for one interactive user at a keyboard. On a server handling concurrent requests, that assumption fails in specific and familiar ways: processes deadlock waiting on each other, modal dialogs appear where no one can dismiss them, and instances outlive their requests until the machine runs out of memory.
The licensing position is equally awkward. A server rendering documents on behalf of many users needs desktop licences that were never intended to cover that use, which is a conversation with a procurement team that rarely goes well.
The alternative is native rendering: a library that parses the format directly and produces output in-process. No second application, no automation layer, no orphaned processes to reap on a schedule.
In Doconut
Doconut renders natively. There is no Office installation, no COM automation and no interop assembly anywhere in the pipeline — which is also what makes container deployment straightforward.
Related terms
Document conversion
Transforming a file from one format into another and producing a new file, as distinct from rendering, which produces a temporary visual representation and no new artifact.
Server-side document rendering
Converting a document into page images on the server, so the browser displays rendered pages rather than parsing the original file itself.
Document viewer SDK
A library you embed in your own application so it can display documents, as distinct from a hosted service you upload documents to. The SDK runs inside your process; the service runs inside somebody else's.