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 116 of 127 production projects for NativeAOT: 113 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 production CLI tool publishes and starts natively, and the row-mapping source generator emits code exercised by the native host. The remaining components use managed deployment: the Chromium browser-PDF bridge, local HTML/PDF workbench, and Avalonia-based OfficeIMO Studio run cross-platform; the document-AI engine, IntelligenceX adapter and headless example target managed .NET 10 without a NativeAOT claim. The Project library, invoice engine, optional PDF adapter and standards validator also use managed cross-platform deployment. The WPF/WebView2 renderer stays on Windows because the .NET SDK rejects trimming for WPF executables.

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 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.