IronPDF on Azure Linux with WEBSITE_RUN_FROM_PACKAGE
Lors du déploiement d'une API .NET utilisant IronPDF sur un service App Azure Linux avec WEBSITE_RUN_FROM_PACKAGE activé, le moteur de rendu Chrome échoue à se déployer et l'application génère une erreur au démarrage.
Error while deploying IronPdf Chrome renderer: 'Multiple issues occurred while trying to deploy Chrome (libatk-1.0.so.0: cannot open shared object file: No such file or directory) (IronInterop.so: cannot open shared object file: No such file or directory) (Read-only file system: '/home/site/wwwroot/runtimes')'
Lorsque WEBSITE_RUN_FROM_PACKAGE est défini, le répertoire /home/site/wwwroot devient en lecture seule. IronPDF doit extraire les binaires du moteur de rendu Chrome natif et les bibliothèques d'exécution vers un emplacement accessible en écriture au démarrage, donc la restriction en lecture seule bloque le déploiement. De plus, l'environnement par défaut Linux de Azure peut ne pas avoir les bibliothèques système requises préinstallées, ce qui cause des erreurs d'objet partagé manquant.
Solution
Trois options sont disponibles en fonction de vos contraintes de déploiement.
Option 1 : Installer les dépendances manquantes via SSH
Accédez au service App via SSH et exécutez les commandes suivantes pour installer les bibliothèques système requises :
apt update
apt install -y libc6-dev libgtk2.0-0 libnss3 libatk-bridge2.0-0 \
libx11-xcb1 libxcb-dri3-0 libdrm-common libgbm1 libasound2 \
libxkbcommon-x11-0 libxrender1 libfontconfig1 libxshmfence1
apt update
apt install -y libc6-dev libgtk2.0-0 libnss3 libatk-bridge2.0-0 \
libx11-xcb1 libxcb-dri3-0 libdrm-common libgbm1 libasound2 \
libxkbcommon-x11-0 libxrender1 libfontconfig1 libxshmfence1
Ceci est une solution temporaire. Les packages installés de cette manière ne persistent pas entre les redémarrages et ne conviennent pas pour les environnements de production qui ont des restrictions de pare-feu sortant. Pour la liste complète des packages requis par distribution Linux, voir le guide de déploiement Linux.
Option 2 : Utiliser un conteneur Docker personnalisé (recommandé pour Linux)
Construisez une image Docker personnalisée basée sur Ubuntu ou Debian, installez les packages système nécessaires avec apt, et incluez les packages NuGet IronPdf et IronPdf.Native.Chrome.Linux dans votre fichier projet. Cette approche donne au moteur de rendu un système de fichiers accessible en écriture et des dépendances préinstallées au moment de la construction de l'image.
Ajoutez les packages NuGet correspondants à votre .csproj :
<PackageReference Include="IronPdf" Version="*" />
<PackageReference Include="IronPdf.Native.Chrome.Linux" Version="*" />
<PackageReference Include="IronPdf" Version="*" />
<PackageReference Include="IronPdf.Native.Chrome.Linux" Version="*" />
Assurez-vous que la version de IronPdf.Native.Chrome.Linux correspond à votre version de package IronPdf. Inclure le package natif dans le projet empêche IronPDF de tenter un téléchargement au moment de l'exécution, ce qui échouerait dans un environnement en lecture seule ou avec des restrictions réseau.
Voir le guide Docker IronPDF pour un exemple complet de Dockerfile.
Option 3 : Migrer vers un service App Windows
Les services App Windows n'ont pas les mêmes restrictions d'autorisation du système de fichiers pour WEBSITE_RUN_FROM_PACKAGE. Les bibliothèques d'exécution Windows d'IronPDF sont nativement prises en charge et peuvent être extraites sans problème. La migration vers un service App Windows élimine entièrement la cause principale.

