Shipping OfficeIMO Applications with NativeAOT

NativeAOT is useful for small command-line tools, containerized document workers, and services where startup time and deployment size matter. OfficeIMO's standard in-process workflows are designed for that model: select the focused packages you need, publish your application for a concrete runtime, and test the documents your service will actually handle.

What works as a native executable

The current matrix validates 152 of 167 production projects for NativeAOT: 143 libraries are fully rooted across the main native host and dedicated hosts for OfficeIMO.Security and OfficeIMO.Provenance.C2pa, the optional Google APIs adapter runs a bounded token-store workflow, the iWork workflow adapter has bounded complete-PDF execution on macOS arm64 under .NET 10, the optional Apple ImageIO adapter executes bounded HEIC decoding and PDF composition on that same runtime, the production CLI tool publishes and starts natively, the Studio engine publishes as a NativeAOT library and completes its document journey through the C interface, and the row-mapping and YAML serializer source generators emit code exercised by native hosts. Most remaining components use managed deployment: the Chromium browser-PDF bridge, local HTML/PDF workbench, and Avalonia-based OfficeIMO Studio run cross-platform; OfficeIMO.JavaScript.Assets distributes JavaScript assets through a managed .NET API without native-publish qualification; the UI-independent Studio core has trim and AOT analyzer evidence without native-publish qualification; the document-AI engine, IntelligenceX adapter and headless example target managed .NET 10 without a NativeAOT claim. The Access library and KSeF client also use managed cross-platform deployment. OfficeIMO.Invoicing.Validation is rooted and runs schema validation in process, but its business-rule validation needs a Java runtime because it runs in an external Java process; only the .NET adapter is native. The iWork PDF profile checks caller-supplied portable fonts, explicit content rejection and atomic cancellation. Native Numbers padding, other architectures and the complete workflow API remain outside that qualification. The WPF/WebView2 renderer stays on Windows because the .NET SDK rejects trimming for WPF executables. The separate iOS host has Debug simulator evidence; Release trimming, device AOT, signing, and physical-device acceptance remain unqualified.

The ImageIO profile compares composed output with independent image references. Its complete API, .NET 8 NativeAOT, iOS device execution and other platforms remain unqualified.

The optional OfficeIMO.Odbc driver has Windows x64 NativeAOT qualification through the Windows ODBC manager and an independent System.Data.Odbc client.

The Draw PDF bridge, OfficeIMO.OpenDocument.Odg.Pdf, has managed conversion and package-consumer evidence. NativeAOT qualification for the complete bridge is separate.

OfficeIMO.Archives extracts Cabinet archives and embedded MSI payloads through managed .NET. NativeAOT qualification is separate.

That project-level matrix is reinforced by eight customer workflow applications, all of which currently pass on both Windows and Linux:

• Word creates, saves, reopens, and inspects a DOCX.
• Excel writes and reloads a typed table.
• PowerPoint creates and duplicates a chart slide with its related parts.
• Markdown and CSV compose or parse real content.
• Reader registers the complete local-format preset and performs structured extraction.
• HTML rendering produces SVG, PNG, and searchable PDF output.

The tests publish and execute on win-x64 and linux-x64 rather than stopping when compilation succeeds. This catches missing metadata, relationship, serialization, and startup behavior that a project setting alone cannot prove. Each scenario uses isolated SDK artifacts so results do not depend on a previous build from another operating system. The complete matrix names each project and the evidence attached to it.

Add NativeAOT to your application

<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
  <PublishAot>true</PublishAot>
</PropertyGroup>

Then publish for the target that will run the application:

dotnet publish -c Release -r linux-x64

Use the normal typed OfficeIMO APIs. If your code asks OfficeIMO or another dependency to discover arbitrary runtime model members, the .NET analyzer may require an explicit model mapping or preservation rule. That warning belongs at the application boundary where the dynamic type is selected.

Optional integrations remain optional

An AOT document worker does not need a browser, cloud SDK, or OCR engine unless the application selects one. OfficeIMO keeps these capabilities in focused packages:

• The dependency-light Google Workspace clients are included in the fully rooted graph. The optional Google.Apis credential package has a bounded native token-store test; live OAuth remains part of the consumer's provider graph.
• Tesseract and process-based OCR execute an external program even when the OfficeIMO host is native.
• The optional Chromium browser-PDF bridge uses HtmlTinkerX and Playwright through the managed cross-platform runtime. It is not presented as NativeAOT-compatible.
• The optional static Mermaid document adapter, OfficeIMO.ChartForgeX.Markdown, has managed .NET 8 and 10 integration evidence. Complete adapter NativeAOT qualification is separate.
• The local HTML/PDF workbench uses its managed cross-platform deployment path. It is not presented as NativeAOT-compatible without separate native-publish proof.
• OfficeIMO Studio uses the managed cross-platform Avalonia desktop runtime. It is not presented as NativeAOT-compatible without separate native-publish proof.
• WPF/WebView2 uses managed Windows deployment and is not presented as NativeAOT-compatible while WPF trimming is rejected by the .NET SDK.

Keeping those boundaries explicit makes a small native Word, Excel, PowerPoint, Markdown, CSV, Reader, or PDF tool practical without pretending every third-party runtime is compiled into the same binary.

Test the workflow, not just startup

For production acceptance, generate or ingest a representative document and verify the useful result. Check paragraph text, table values, formulas, slide relationships, conversion diagnostics, or searchable PDF text. Repeat the test for each operating system, architecture, font set, and optional provider you intend to ship.

The NativeAOT deployment guide includes the current package-family guidance, repository verification command, and alternatives such as trimming, ReadyToRun, and single-file deployment.