IronPDF on Azure Linux with WEBSITE_RUN_FROM_PACKAGE
Bei der Bereitstellung einer .NET-API unter Verwendung von IronPDF auf einem Azure Linux App Service mit aktiviertem WEBSITE_RUN_FROM_PACKAGE schlägt der Chrome-Renderer beim Bereitstellen fehl und die Anwendung gibt beim Start einen Fehler aus.
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')'
Wenn WEBSITE_RUN_FROM_PACKAGE gesetzt ist, wird das Verzeichnis /home/site/wwwroot schreibgeschützt. IronPDF muss native Chrome-Renderer-Binärdateien und Laufzeitbibliotheken an einem beschreibbaren Ort beim Start extrahieren, daher blockiert die schreibgeschützte Einschränkung die Bereitstellung. Darüber hinaus verfügt Azure's Standard-Linux-Umgebung möglicherweise nicht über die erforderlichen Systembibliotheken, was zu den fehlenden Shared-Object-Fehlern führt.
Lösung
Je nach Ihren Bereitstellungsbeschränkungen stehen drei Optionen zur Verfügung.
Option 1: Fehlende Abhängigkeiten über SSH installieren
Greifen Sie per SSH auf den App Service zu und führen Sie die folgenden Befehle aus, um die erforderlichen Systembibliotheken zu installieren:
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
Dies ist eine temporäre Lösung. Auf diese Weise installierte Pakete bleiben beim Neustart nicht erhalten und sind nicht geeignet für Produktionsumgebungen mit ausgehenden Firewall-Beschränkungen. Für die vollständige Liste der benötigten Pakete nach Linux-Distribution, siehe den Linux Bereitstellungsleitfaden.
Option 2: Verwenden Sie einen benutzerdefinierten Docker-Container (empfohlen für Linux)
Erstellen Sie ein benutzerdefiniertes Docker-Image basierend auf Ubuntu oder Debian, installieren Sie die erforderlichen Systempakete mit apt und fügen Sie die IronPdf und IronPdf.Native.Chrome.Linux NuGet-Pakete in Ihre Projektdatei ein. Dieser Ansatz bietet dem Renderer ein beschreibbares Dateisystem und vorinstallierte Abhängigkeiten zur Bildaufbauzeit.
Fügen Sie die passenden NuGet-Pakete zu Ihrem .csproj hinzu:
<PackageReference Include="IronPdf" Version="*" />
<PackageReference Include="IronPdf.Native.Chrome.Linux" Version="*" />
<PackageReference Include="IronPdf" Version="*" />
<PackageReference Include="IronPdf.Native.Chrome.Linux" Version="*" />
Stellen Sie sicher, dass die Version von IronPdf.Native.Chrome.Linux mit Ihrer IronPdf Paketversion übereinstimmt. Das Einbeziehen des nativen Pakets im Projekt verhindert, dass IronPDF versucht, zur Laufzeit einen Download durchzuführen, was in einer schreibgeschützten oder netzwerkbeschränkten Umgebung fehlschlagen würde.
Siehe den IronPDF Docker-Leitfaden für ein vollständiges Dockerfile-Beispiel.
Option 3: Umstieg auf einen Windows App Service
Windows App Services haben nicht die gleichen Dateisystem-Berechtigungseinschränkungen für WEBSITE_RUN_FROM_PACKAGE. Die Windows-Laufzeitbibliotheken von IronPDF werden nativ unterstützt und können ohne Probleme extrahiert werden. Der Umstieg auf einen Windows App Service beseitigt die eigentliche Ursache vollständig.

