Veröffentlichen von .NET-Apps für macOS

Das Veröffentlichen von .NET-Anwendungen für macOS erfordert aufgrund der Sicherheitsanforderungen von Apple mehrere zusätzliche Schritte im Vergleich zu anderen Plattformen.

Voraussetzungen

Stellen Sie vor der Veröffentlichung Ihrer .NET-Anwendung für macOS Folgendes sicher:

  • Apple-Entwicklerkonto: Wird benötigt für Code-Signierung und Notarisierung.
  • Xcode-Befehlszeilentools: Stellt codesign, altool und andere Hilfsprogramme bereit.
  • .NET SDK: Stellen Sie sicher, dass das neueste .NET SDK installiert ist.

Erstellen Ihrer App mit .NET SDK

Verwenden Sie eine der in der .NET-Anwendungsveröffentlichungsübersicht beschriebenen Methoden, um eine Anwendung zu erstellen. Sie können entweder eine frameworkabhängige oder eigenständige Anwendung erstellen.

Signieren und Notarisieren Ihrer App

Verwenden Sie die Entwicklerdokumentation von Apple , um die systemeigenen Binärdateien der App zu signieren und zu notieren. .NET erstellt eine systemeigene apphost-ausführbare Datei als Einstiegspunkt für Ihre App. Dieser Apphost muss signiert sein, und wenn Ihre App spezielle Funktionen verwendet, muss sie den entsprechenden Berechtigungen zugewiesen werden.

Anwendungsidentität

Anwendungsidentität ist der Codesignaturbezeichner (wie im CFBundleIdentifier Feld im Info.plist Manifest angegeben), der macOS verwendet, um Zugriffsentscheidungen und Richtlinien einer bestimmten App zuzuordnen.

Apps, die Zugriffsentscheidungen für Geheimnisse oder andere Schlüsselbundelemente speichern, müssen mithilfe einer ausführbaren Apphost-Datei wie MyApp verteilt und gestartet werden, nicht mit dem dotnet-Startprogramm (dotnet MyApp.dll). Der app-spezifische Zustand muss einem eindeutigen, stabilen Codesignaturbezeichner zugeordnet werden. Der dotnet Launcher wird für dieses Szenario nicht unterstützt.

Softwareverwaltungslösungen können die Signaturidentität Ihres Apphost verwenden, um appspezifische Startrichtlinien separat von anderen .NET gehosteten Anwendungen anzuwenden, die den dotnet Host verwenden.

Weisen Sie dem Apphost einen eindeutigen, stabilen Codesignaturbezeichner zu und signieren Sie Versionen mit einem Entwickler-ID-Anwendungszertifikat aus Ihrem Apple Developer-Team. Sorgen Sie dafür, dass der Bezeichner und das Team über Updates hinweg konsistent bleiben. Die Änderung einer der beiden Optionen kann erfordern, dass Benutzer und Administratoren Genehmigungen verlängern.

Ausführliche Informationen finden Sie in den Anleitungen von Apple zu Metadaten für eigenständige Tools und zum Signieren einzelner ausführbarer Dateien.

Berechtigungen für Apps, die nicht als native AOT veröffentlicht wurden

Für Apps, die nicht als native AOT veröffentlicht wurden, ist die com.apple.security.cs.allow-jit Berechtigung erforderlich.

Berechtigungen für Apps, die als native AOT veröffentlicht wurden

Für Apps, die als native AOT veröffentlicht wurden, sind keine Berechtigungen erforderlich.

Optionale Berechtigungen für Debugging und Diagnose

Die folgenden Berechtigungen ermöglichen zusätzliche Debugging- und Diagnosefunktionen:

  • com.apple.security.get-task-allow: Erforderlich für die Dumpauflistung mit createdump und dotnet dump.
  • com.apple.security.cs.debugger: Erforderlich, um einen Debugger an den Prozess anzufügen.

Warnung

Wenn Sie Ihre App nicht signieren und notarisieren, kann die Anwendung beim Ausführen eines eingeschränkten Vorgangs abstürzen.

Universelle Binärdateien

macOS unterstützt universelle Binärdateien: eine einzelne Mach-O Datei, die Computercode für mehrere CPU-Architekturen enthält. macOS wählt das Segment aus, das dem aktuellen Prozessor entspricht, sodass eine Datei nativ sowohl auf Apple Silicon-Computern (arm64) als auch auf Intel-Computern (x64) ausgeführt wird.

.NET erzeugt keine universellen Binärdateien direkt. Stattdessen veröffentlichen Sie Ihre App einmal pro Architektur und führen die beiden nativen ausführbaren Dateien mit dem Apple-Tool lipo zusammen. Zwei .NET Veröffentlichungsmodi erzeugen eine eigenständige native ausführbare Datei, die Sie auf diese Weise zusammenführen können:

Eine universelle Einzeldatei-Binärdatei veröffentlichen

Veröffentlichen Sie die App einmal pro Architektur in separaten Verzeichnissen:

dotnet publish -c Release -r osx-arm64 --self-contained true \
    -p:PublishSingleFile=true -o out/osx-arm64

dotnet publish -c Release -r osx-x64 --self-contained true \
    -p:PublishSingleFile=true -o out/osx-x64

Führen Sie dann die beiden ausführbaren Dateien zusammen, und signieren Sie das Ergebnis erneut:

mkdir -p out/universal
lipo -create -output out/universal/MyApp out/osx-arm64/MyApp out/osx-x64/MyApp
codesign --force --sign - out/universal/MyApp

Eine eigenständige Single-File-Veröffentlichung bettet die Laufzeit, die verwalteten Assemblys und die nativen Bibliotheken in der ausführbaren Datei selbst ein, sodass die zusammengeführte Datei die vollständige App ist. Die universelle Binärdatei ist ungefähr die Summe der beiden Eingaben.

Kopieren Sie alle verbleibenden Dateien aus einem der architekturspezifischen Ausgabeverzeichnisse (z. B. appsettings.json oder aus dem Bundle ausgeschlossene Dateien) neben der zusammengeführten ausführbaren Datei.

Veröffentlichen einer universellen Native AOT-Binärdatei

Die Schritte sind dieselben wie bei einer einzelnen Datei, ersetzen Sie jedoch die Eigenschaften der einzelnen Datei durch PublishAot:

dotnet publish -c Release -r osx-arm64 -p:PublishAot=true -o out/osx-arm64
dotnet publish -c Release -r osx-x64   -p:PublishAot=true -o out/osx-x64

mkdir -p out/universal
lipo -create -output out/universal/MyApp out/osx-arm64/MyApp out/osx-x64/MyApp
codesign --force --sign - out/universal/MyApp

Native AOT erzeugt einen deutlich kleineren Output als die Single-File-Veröffentlichung, sodass auch die Universal-Binärdatei klein bleibt.

Native AOT erzeugt außerdem pro Architektur ein MyApp.dSYM-Debugsymbolbundle. Um Symbole für beide Segmente beizubehalten, behalten Sie die Verzeichnisse pro Architektur bei oder führen Sie die DWARF-Binärdateien innerhalb der Bundles mit lipo zusammen.