Публикация приложений .NET для macOS

Для публикации приложений .NET для macOS требуется несколько дополнительных шагов по сравнению с другими платформами из-за требований к безопасности Apple.

Предпосылки

Перед публикацией приложения .NET для macOS убедитесь в следующем:

  • Учетная запись разработчика Apple: необходимая для подписывания кода и нотации.
  • Средства командной строки Xcode: предоставляют codesign, altool и другие служебные программы.
  • Пакет SDK для .NET. Убедитесь, что установлен последний пакет SDK для .NET.

Создание приложения с помощью пакета SDK для .NET

Используйте один из методов, описанных в обзоре публикации приложений .NET , для создания приложения. Вы можете создать приложение, зависящее от платформы, или автономное приложение.

Подпишите и заверьте у нотариуса ваше приложение.

Используйте документацию разработчика Apple для подписывания и нотирования собственных двоичных файлов приложения. .NET создает собственный исполняемый файл apphost в качестве точки входа для приложения. Этот apphost должен быть подписан, и если приложение использует специальные возможности, ему должны быть предоставлены соответствующие права.

Идентификатор приложения

Идентификатор приложения — это идентификатор подписывания кода (как указано в поле CFBundleIdentifier манифеста Info.plist), который macOS использует для связывания решений и политик доступа с определённым приложением.

Приложения, которые сохраняют решения о доступе для секретов или других элементов связки ключей, должны распространяться и запускаться с помощью исполняемого файла apphost, например MyApp, а не dotnet средства запуска (dotnet MyApp.dll). Состояние конкретного приложения должно быть связано с уникальным стабильным идентификатором подписи кода. Средство dotnet запуска не поддерживается для этого сценария.

Решения по управлению программным обеспечением могут использовать удостоверение подписи apphost для применения политик запуска для конкретного приложения отдельно от других .NET-размещенных приложений, использующих host dotnet.

Присвойте apphost уникальный, стабильный идентификатор подписи кода и подписывайте выпуски с помощью сертификата Developer ID Application от вашей команды разработчиков Apple. Сохраняйте согласованность идентификатора и команды между обновлениями. Изменение любого из этих параметров может требовать от пользователей и администраторов возобновления подтверждений.

Дополнительные сведения см. в руководстве Apple по метаданным для автономных инструментов и подписи отдельных исполняемых файлов.

Разрешения для приложений, не опубликованных как независимый AOT

Для приложений, не опубликованных как Собственный AOT, требуется com.apple.security.cs.allow-jit разрешение.

Права для приложений, опубликованных как Native AOT

Для приложений, опубликованных как Native AOT, права не требуются.

Необязательные права для отладки и диагностики

Следующие права обеспечивают дополнительные возможности отладки и диагностики:

  • com.apple.security.get-task-allow: требуется для сбора дампов с использованием createdump и dotnet dump.
  • com.apple.security.cs.debugger: требуется для подключения отладчика к процессу.

Предупреждение

Несоблюдение процедуры подписания и нотариального заверения вашего приложения может привести к сбою приложения при выполнении ограниченных операций.

Универсальные бинарные файлы

macOS поддерживает универсальные двоичные файлы: один файл Mach-O, содержащий код компьютера для нескольких архитектур ЦП. macOS выбирает срез, соответствующий текущему процессору, поэтому один файл нативно работает как на машинах Apple silicon (arm64), так и на Intel (x64).

.NET не создает универсальные двоичные файлы напрямую. Вместо этого вы публикуете приложение отдельно для каждой архитектуры и объединяете два нативных исполняемых файла с помощью инструмента Apple lipo. Два режима публикации .NET создают автономный собственный исполняемый файл, который можно объединить таким образом:

Опубликовать универсальный двоичный файл в виде одного файла

Опубликуйте приложение по одному разу для каждой архитектуры в отдельные каталоги:

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

Затем объедините два исполняемых файла и повторно запишите результат:

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

Локальная публикация с одним файлом внедряет среду выполнения, управляемые сборки и собственные библиотеки в исполняемый файл, поэтому объединенный файл является полным приложением. Универсальный двоичный файл примерно равен сумме двух входных данных.

Скопируйте все оставшиеся файлы из одного из каталогов выходных данных для каждой архитектуры (например, или файлов, appsettings.json исключенных из пакета) рядом с объединенным исполняемым файлом.

Опубликовать универсальный двоичный файл Native AOT

Шаги такие же, как для одного файла, но замените свойства одного файла на 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 создает значительно меньший выходной файл, чем публикация в виде одного файла, поэтому универсальный двоичный файл также остается небольшим.

Native AOT также создаёт пакет MyApp.dSYM отладочных символов для каждой архитектуры. Чтобы сохранить символы для обеих архитектур, сохраните каталоги по архитектурам или объедините бинарные файлы DWARF внутри пакетов с помощью lipo.

  • Последнее обновление: