Iron Software Logo
CUSTOMER HUB
Iron Software Customer Hub Logo
Licenses Tickets
Sign in
Skip to content
English
Sign in
Go to ironsoftware.com
  • There are no suggestions because the search field is empty.

IronPDF on Azure App Service: Ninject Startup Crash (WEBSITE_RUN_FROM_PACKAGE = 1)

Overview

IronPDF can crash at startup on Azure App Service and Azure Functions when the app is deployed with WEBSITE_RUN_FROM_PACKAGE = 1. That setting mounts the app root (C:\home\site\wwwroot) as a read-only package filesystem. On startup IronPDF runs a file system scan — a side effect of Ninject's default extension auto-loading, not something IronPDF intentionally requires — and the scan fails on the read-only mount, throwing System.IO.FileNotFoundException before any PDF work runs (often at the first IronPDF call, such as setting the license key). Setting WEBSITE_RUN_FROM_PACKAGE = 0 and redeploying resolves it.

Environment

  • OS: Windows (win-x64)
  • Hosting: Azure App Service / Azure Functions, zip/package deployment (WEBSITE_RUN_FROM_PACKAGE = 1)
  • Language/Runtime: .NET 10

Version Metadata

  • Version found: 2026.7.0.2, 2025.12.2, and 2025.3.6
  • Version resolved: N/A

Cause

IronPDF currently performs a file system scan on startup by a default setting. This scan isn't something IronPDF intentionally requires — it is a side effect of Ninject's default extension auto-loading. When WEBSITE_RUN_FROM_PACKAGE = 1, C:\home\site\wwwroot is read-only, so the scan throws FileNotFoundException and initialization stops. We have confirmed this as a bug and logged a development ticket to address it.

Solution

In your Azure App Settings, set the following and then redeploy: 
WEBSITE_RUN_FROM_PACKAGE = 0

A few important notes:

  • If you deploy from Visual Studio, uncheck Run from package file (recommended) during the Publish step.

  • Depending on how your deployment pipeline is set up, this setting may be applied from several different places. We'd recommend exploring where it is defined and where it might be overwritten.
  • To apply the change properly, you must redeploy.

For native IronPDF users (not using the remote IronPDF engine)

This applies regardless of the file system scan fix above. At startup, IronPDF needs to extract the native Chrome renderer binaries and runtime libraries to a writable location. When WEBSITE_RUN_FROM_PACKAGE is enabled, C:\home\site\wwwroot becomes read-only, which blocks this extraction. For this reason, native IronPDF users must set WEBSITE_RUN_FROM_PACKAGE = 0 as a mandatory step, independent of the bug fix above.

More details: https://ironpdf.com/troubleshooting/azure-linux-website-run-from-package/

Workarounds That Don't Work

  • Moving the first IronPDF call out of startup into an on-demand endpoint — the crash still happens on first use.
  • Switching between WEBSITE_RUN_FROM_ZIP and WEBSITE_RUN_FROM_PACKAGE — both mount read-only and fail the same way.
  • Using the remote IronPdfEngine to avoid local binaries — the startup scan still runs first, so it fails before the remote connection is used.
  • Setting Installation.TempFolderPath to a writable path — the crash happens before that setting is read, so it does not reliably help.

Copyright © 2026, Iron Software