Frequently Asked Questions

No. OfficeIMO uses managed document engines and focused package dependencies; it does not require Microsoft Office, COM automation, or Office interop assemblies at runtime. Optional desktop Office checks are validation oracles, not runtime dependencies.

OfficeIMO 3.1 classifies and reads modern and legacy Word, Excel, and PowerPoint families, writes documented native subsets, and reports conversion coverage by operation and fidelity. Use the compatibility dashboard for tracked behaviors, fallbacks, and deliberate blocks.

OfficeIMO 3.1 targets .NET 8.0, .NET 10.0, .NET Standard 2.0, and .NET Framework 4.7.2.

Yes. The OfficeIMO packages themselves are published under the MIT License. However, some optional package families build on third-party dependencies with their own upstream terms, so commercial teams should also review our Third-Party Dependencies page during OSS approval.

OfficeIMO is an MIT-licensed, source-available document platform for .NET and PowerShell with modern and legacy Office support, focused packages, explicit conversion-fidelity policies, and no runtime royalty. Commercial suites can provide broader portfolio coverage, more mature rendering for some workloads, formal support, and procurement SLAs. Compare the exact formats, operations, fidelity, deployment model, and support obligations your application needs on our evaluation page.

Yes. Because OfficeIMO is COM-free and runs on .NET, it fits well in Linux containers, GitHub Actions, Azure DevOps, and other CI/CD environments. For rendering-heavy scenarios such as PDF output, validate the fonts and native dependencies you plan to ship with your container image.

PSWriteOffice is the PowerShell surface over the OfficeIMO document platform. Its command catalog is generated from the module manifest used for this release, covering Word, Excel, PowerPoint, PDF, Reader, Visio, text, open-format, email, and conversion workflows.

Yes, within each package's documented format and feature boundaries. Word, Excel, and PowerPoint expose load and edit workflows for supported content. OfficeIMO.Reader provides a normalized extraction API through selective format handlers or OfficeIMO.Reader.All.

The OfficeIMO 3.2 validation matrix covers 97 of the 99 production projects. CI fully roots 95 library assemblies, runs a bounded native workflow for the optional Google APIs credential adapter, and publishes and starts the production CLI tool on Windows and Linux. The Chromium browser-PDF bridge uses managed cross-platform deployment, while the WPF/WebView2 renderer uses managed Windows deployment. Check the NativeAOT deployment guide and project matrix for the exact package and runtime path.

The core Office document packages are built on DocumentFormat.OpenXml and the first-party OfficeIMO.Core foundation. Drawing primitives remain in the OfficeIMO.Drawing namespace. HTML converter packages use AngleSharp, Excel carries compatibility helper packages on older targets, and the PDF packages use the first-party OfficeIMO.Pdf engine instead of external PDF/runtime layout libraries. The Markdown, CSV, Core, and PDF packages stay dependency-light. See the Third-Party Dependencies page for the package-by-package breakdown and upstream license notes.

Yes. The OfficeIMO.Word.Pdf and OfficeIMO.Excel.Pdf converter packages support PDF export without Office. There are also converters for Word-to-HTML and Word-to-Markdown.

OfficeIMO.Excel supports parallel execution for bulk operations like AutoFit and bulk writes. Each document instance is independent and can be used on separate threads. Concurrent access to a single document instance is not supported.