.NET-apps voor macOS publiceren

Voor het publiceren van .NET-toepassingen voor macOS zijn verschillende extra stappen vereist in vergelijking met andere platforms, vanwege de beveiligingsvereisten van Apple.

Vereiste voorwaarden

Voordat u uw .NET-toepassing voor macOS publiceert, moet u het volgende hebben:

  • Apple Developer-account: vereist voor ondertekening en notarisatie van code.
  • Xcode-opdrachtregelprogramma's: biedt codesign, altool, en andere hulpprogramma's.
  • .NET SDK: Zorg ervoor dat u de nieuwste .NET SDK hebt geïnstalleerd.

Uw app produceren met behulp van .NET SDK

Gebruik een van de methoden die worden beschreven in het publicatieoverzicht van .NET-toepassingen om een toepassing te produceren. U kunt een frameworkafhankelijke of zelfstandige toepassing maken.

Uw app ondertekenen en notariseren

Gebruik de ontwikkelaarsdocumentatie van Apple om de systeemeigen binaire bestanden van de app te ondertekenen en te notariseren. .NET maakt een systeemeigen apphost uitvoerbaar bestand als het toegangspunt voor uw app. Deze apphost moet zijn ondertekend en als uw app gebruikmaakt van speciale mogelijkheden, moet deze de juiste rechten worden toegewezen.

Toepassingsidentiteit

Toepassingsidentiteit is de id voor ondertekening van programmacode (zoals opgegeven in het CFBundleIdentifier veld in het Info.plist manifest) die door macOS wordt gebruikt om toegangsbeslissingen en beleid te koppelen aan een specifieke app.

Apps die toegangsbeslissingen voor secrets of andere sleutelhangeronderdelen opslaan, moeten worden gedistribueerd en gestart met behulp van een uitvoerbaar apphost-bestand, zoals MyApp, niet het dotnet startprogramma (dotnet MyApp.dll). App-specifieke toestand moet worden gekoppeld aan een unieke, stabiele code-signing-ID. Het dotnet launcher wordt niet ondersteund voor dit scenario.

Softwarebeheeroplossingen kunnen de ondertekeningsidentiteit van uw apphost gebruiken om app-specifiek startbeleid afzonderlijk toe te passen van andere .NET gehoste toepassingen die gebruikmaken van de dotnet host.

Geef de apphost een unieke, stabiele id voor ondertekening van programmacode en onderteken releases met een Developer ID Application-certificaat van uw Apple Developer-team. Houd de id en het team consistent bij updates. Als u een van beide wijzigt, moeten gebruikers en beheerders mogelijk goedkeuringen vernieuwen.

Zie de richtlijnen van Apple voor metagegevens voor zelfstandige hulpprogramma's en het ondertekenen van afzonderlijke uitvoerbare bestanden voor meer informatie.

Rechten voor apps die niet zijn gepubliceerd als Native AOT

Voor apps die niet als Native AOT zijn gepubliceerd, is het com.apple.security.cs.allow-jit recht vereist.

Rechten voor apps die zijn gepubliceerd als Native AOT

Voor apps die als systeemeigen AOT zijn gepubliceerd, zijn er geen rechten vereist.

Optionele rechten voor foutopsporing en diagnose

Met de volgende rechten kunt u aanvullende foutopsporings- en diagnostische mogelijkheden inschakelen:

  • com.apple.security.get-task-allow: Nodig voor dumpverzameling met createdump en dotnet dump.
  • com.apple.security.cs.debugger: Nodig om een foutopsporingsprogramma toe te voegen aan het proces.

Waarschuwing

Als u uw app niet kunt ondertekenen en notariseren, kan dit ertoe leiden dat de toepassing vastloopt tijdens het uitvoeren van een beperkte bewerking.

Universal binaries

macOS ondersteunt universele binaire bestanden: één Mach-O-bestand dat machinecode bevat voor meer dan één CPU-architectuur. macOS selecteert de slice die overeenkomt met de huidige processor, dus één bestand draait native op zowel Apple silicon-machines (arm64) als Intel-machines (x64).

.NET produceert niet rechtstreeks universele binaire bestanden. In plaats daarvan publiceert u uw app eenmaal per architectuur en voegt u de twee systeemeigen uitvoerbare bestanden samen met de Apple-tool lipo. Twee .NET publicatiemodi produceren een zelfstandig systeemeigen uitvoerbaar bestand dat u op deze manier kunt samenvoegen:

Een universeel binair bestand als één bestand publiceren

Publiceer de app eenmaal per architectuur in afzonderlijke mappen:

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

Voeg vervolgens de twee uitvoerbare bestanden samen en onderteken het resultaat opnieuw:

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

Een zelfstandige single-file-publicatie neemt de runtime, de beheerde assembly's en de systeemeigen bibliotheken op in het uitvoerbare bestand zelf, zodat het samengevoegde bestand de volledige app is. Het universeel binair bestand is ongeveer de som van de twee invoerwaarden.

Kopieer alle resterende bestanden uit een van de uitvoermappen per architectuur (bijvoorbeeld appsettings.json of bestanden die zijn uitgesloten van de bundel) naast het samengevoegde uitvoerbare bestand.

Een systeemeigen AOT universeel binair bestand publiceren

De stappen zijn hetzelfde als voor één bestand, maar vervang de eigenschappen voor één bestand door 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

Systeemeigen AOT produceert veel kleinere uitvoer dan publiceren met één bestand, dus het universele binaire bestand blijft ook klein.

Systeemeigen AOT genereert ook een MyApp.dSYM foutopsporingssymboolbundel per architectuur. Als u symbolen voor beide segmenten wilt behouden, houdt u de mappen per architectuur bij of voegt u de DWARF binaire bestanden in de bundels samen met lipo.

  • Laatst bijgewerkt om