Frameworks mac os что это

Что такое Framework в Mac OS X? (*.framework папки)

Хорошо, я знаю, что такое основа в реальной жизни. Я видел некоторые фреймворки, которые содержат некоторые файлы заголовков и двоичные файлы. Это оно? Существует ли в инфраструктуре OS X специальные функции, отличные от того, что вы являетесь папкой с заголовками и библиотеками, которые вы связываете с вашим приложением?

Информация о структуре

Структура — это пакет (структурированный каталог), который содержит динамическую общую библиотеку вместе с связанными ресурсами, такими как файлы nib, файлы изображений и файлы заголовков. Когда вы разрабатываете приложение, ваш проект привязывается к одной или нескольким фреймворкам. Например, проекты приложений iPhone по умолчанию привязаны к фреймворкам Foundation, UIKit и Core Graphics. Ваш код обращается к возможностям инфраструктуры через интерфейс прикладного программирования (API), который публикуется каркасом через его файлы заголовков. Поскольку библиотека динамически распределена, несколько приложений могут одновременно обращаться к коду инфраструктуры и ресурсам. Система загружает код и ресурсы фреймворка в память по мере необходимости и разделяет одну копию ресурса среди всех приложений.

Рамки предлагают следующие преимущества перед статическими библиотеками и другими типами динамических разделяемых библиотек:

Структура структур, связанных, но разделенных, ресурсов вместе. Эта группировка упрощает установку, удаление и поиск этих ресурсов. Рамки могут включать более широкий набор типов ресурсов, чем библиотеки. Например, структура может включать любые соответствующие файлы заголовков и документацию. В один и тот же комплект можно включить несколько версий фреймворка. Это позволяет быть обратно совместимым со старыми программами. Только одна копия ресурсов только для чтения основывается физически в памяти в любой момент времени, независимо от того, сколько процессов использует эти ресурсы. Это совместное использование ресурсов уменьшает объем памяти системы и помогает повысить производительность.

Источник

Безопасно ли вручную удалять фреймворки неиспользуемых программ из каталога Mac OS X /Library/Frameworks/?

мне пришлось искать в папке Frameworks на моем mac ( /Library/Frameworks/ ) для удаления программы. Но теперь, когда я смотрю дальше в папку, я вижу некоторые программы, которые я когда-то установил, но по некоторым причинам удалил через некоторое время.

Мне интересно, если я могу удалить рамки этих программ, как я не хочу, чтобы переустановить эти программы на этом mac больше.

Я читал, что рамки «иерархический каталог, который инкапсулирует общие ресурсы» как я читал на сайте Apple. Потому что я ничего не знаю об этом материале, я не просто хочу что-то удалить.

Итак, мой вопрос, Безопасно ли удалять фреймворки из неиспользуемых и деинсталлированных программ без проблем с другими программами или самим компьютером?

1 ответов

если ничего не использует их, да

The .framework файлы /Library/Frameworks/ действительно, файлы, которые предназначены для быть разделены. Например, у меня сейчас есть Mono.framework в моей папке, которая будет использоваться всеми приложениями, созданными с Mono.

вы не будете иметь никаких проблем с macOS, Если вы удалите эти файлы, так как он имеет свою собственную папку Framework в /System/Library/Frameworks (и вы не должны удалить). Таким образом, единственный риск с удалением этих файлов, если приложение или служба просить его.

к сожалению, нет хорошего способа узнать, какие приложения требуют каких фреймворков, поэтому вам придется использовать образованную догадку. Стратегии, которые я могу порекомендовать:

• посмотрите на название: один из моих фреймворков HPSmartPrint.framework , что, я уверен, для принтеров HP. Я не владел принтером HP около восьми лет, поэтому я уверен, что он не используется.
• посмотрите на дату Изменено: если что-то вы используете регулярно использует рамки, шансы хороши, что он собирается попытаться сохранить его в актуальном состоянии. У меня есть один фреймворк, который был последний раз изменен в 2009 году, и вместе с именем, я уверен, что он не используется.
• использовать просмотрщик пакетов: если у вас есть догадка о том, что установил его, вы можете использовать инструмент, как Подозрительный Пакет для просмотра файлов, устанавливаемых пакетом. Мне посчастливилось найти .установщик pkg Онлайн для старого инструмента VPN, который я использовал. Запуск его через подозрительный пакет показал, что он действительно создал один из файлов framework в моем Library/Frameworks папка.

конечно, если вы удалите основу, которая требуется что — то вы используете, переустановка этого приложения должны добавить его обратно на свой компьютер.

Источник

Установка .NET в macOS

В этой статье вы узнаете, как установить .NET в macOS. .NET состоит из среды выполнения и пакета SDK. Среда выполнения используется для запуска приложения .NET и может не включаться в состав приложения. Пакет SDK используется для создания приложений и библиотек .NET. Среда выполнения .NET всегда устанавливается вместе с пакетом SDK.

.NET 5.0 является последней версией.

Поддерживаемые выпуски

В приведенной ниже таблице содержится список поддерживаемых сейчас выпусков .NET и версий macOS, в которых они поддерживаются. Эти версии будут поддерживаться до окончания срока поддержки .NET.

• Значок ✔️ означает, что версия .NET Core поддерживается.
• Значок ❌️ означает, что версия .NET Core не поддерживается.

Операционная система	.NET Core 2.1	.NET Core 3.1	.NET 5.0
macOS 11.0 «Big Sur»	✔️ 2.1 (заметки о выпуске)	✔️ 3.1 (заметки о выпуске)	✔️ 5.0 (заметки о выпуске)
macOS 10.15 «Catalina»	✔️ 2.1 (заметки о выпуске)	✔️ 3.1 (заметки о выпуске)	✔️ 5.0 (заметки о выпуске)
macOS 10.14 «Mojave»	✔️ 2.1 (заметки о выпуске)	✔️ 3.1 (заметки о выпуске)	✔️ 5.0 (заметки о выпуске)
macOS 10.13 «High Sierra»	✔️ 2.1 (заметки о выпуске)	✔️ 3.1 (заметки о выпуске)	✔️ 5.0 (заметки о выпуске)
macOS 10.12 «Sierra»	✔️ 2.1 (заметки о выпуске)	❌ 3.1 (заметки о выпуске)	❌ 5.0 (заметки о выпуске)

Неподдерживаемые выпуски

Следующие версии .NET больше не поддерживаются (❌). (но остаются доступными для скачивания):

Сведения о среде выполнения

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

В macOS можно установить две разные среды выполнения:

Среда выполнения ASP.NET Core
Используется для запуска приложений ASP.NET Core. Включает среду выполнения .NET.

Среда выполнения .NET
Простейшая среда выполнения, в состав которой не входят какие-либо другие среды выполнения. Чтобы обеспечить максимальный уровень совместимости с приложениями .NET, настоятельно рекомендуется устанавливать среду выполнения ASP.NET Core.

Сведения о пакете SDK

Пакет SDK используется для создания и публикации приложений и библиотек .NET. При установке пакета SDK также устанавливаются обе среды выполнения: ASP.NET Core и .NET.

Зависимости

Платформа .NET поддерживается в следующих выпусках macOS:

Символ + представляет минимальную версию.

Версия .NET Core	macOS	Архитектуры	Дополнительные сведения
5,0	High Sierra (10.13+)	X64	Дополнительные сведения
3.1	High Sierra (10.13+)	X64	Дополнительные сведения
3.0	High Sierra (10.13+)	X64	Дополнительные сведения
2.2	Sierra (10.12+)	X64	Дополнительные сведения
2.1	Sierra (10.12+)	X64	Дополнительные сведения

Начиная с macOS Catalina (версия 10.15) все программное обеспечение, созданное после 1 июня 2019 года и распространяемое с идентификатором разработчика, должно быть заверено. Это требование относится к среде выполнения .NET, пакету SDK для .NET и программному обеспечению, созданному с помощью .NET.

Среда выполнения и установщики пакета SDK для .NET версии 5.0 и .NET Core 3.1, 3.0 и 2.1 были заверены с 18 февраля 2020 г. Более ранние версии не заверены. При запуске незаверенного приложения появится ошибка, аналогичная следующей:

Дополнительные сведения о том, как принудительное заверение влияет на .NET (и ваши приложения .NET), см. в разделе Работа с заверением macOS Catalina.

libgdiplus

Приложения .NET, которые используют сборку System.Drawing.Common, требуют установки libgdiplus.

Легко получить libgdiplus можно с помощью диспетчера пакетов Homebrew («brew») для macOS. После установки brew установите libgdiplus, выполнив следующие команды в окне терминала (аналог командной строки):

Установка с помощью установщика

В macOS есть автономные установщики, которые можно использовать для установки пакета SDK для .NET 5.0:

Скачивание и установка вручную

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

Сначала скачайте двоичный выпуск пакета SDK или среды выполнения с одного из следующих сайтов. При установке пакета SDK для .NET не нужно устанавливать соответствующую среду выполнения:

Затем извлеките скачанный файл и используйте команду export , чтобы задать для переменной DOTNET_ROOT расположение извлеченной папки, а затем проверьте включение .NET в переменную PATH. После этого команды .NET CLI станут доступны в терминале.

Кроме того, после скачивания двоичного файла .NET можно выполнить следующие команды из каталога, в котором сохранен файл, для извлечения среды выполнения. После этого команды .NET CLI также станут доступны в терминале, и будут заданы нужные переменные среды. Обязательно измените значение DOTNET_FILE на имя скачанного двоичного файла:

Приведенные выше команды export сделают команды .NET CLI доступными только для сеанса терминала, в котором производился запуск.

Вы можете изменить профиль оболочки, чтобы добавить команды окончательно. Существует несколько различных оболочек, доступных для Linux, и каждая из них имеет свой профиль. Пример:

Оболочка Bash:

/.bashrc
Оболочка Korn:

/.kshrc или .profile
Оболочка Z:

Измените соответствующий исходный файл оболочки и добавьте :$HOME/dotnet в конец существующего оператора PATH . Если оператор PATH не указан, добавьте новую строку с export PATH=$PATH:$HOME/dotnet .

Кроме того, добавьте export DOTNET_ROOT=$HOME/dotnet в конец файла.

Такой подход позволяет устанавливать разные версии в отдельные расположения и выбирать, какие из них следует использовать для каждого приложения.

Установка с помощью Visual Studio для Mac

Visual Studio для Mac устанавливает пакет SDK для .NET, если выбрана рабочая нагрузка .NET. Чтобы приступить к разработке в .NET на macOS, ознакомьтесь со статьей Установка Visual Studio 2019 для Mac.

Версия пакета SDK для .NET	Версия Visual Studio
5,0	Visual Studio 2019 для Mac версии 8.8 или более поздней.
3.1	Visual Studio 2019 для Mac версии 8.4 или более поздней.
2.1	Visual Studio 2019 для Mac версии 8.0 или более поздней.

Установка вместе с Visual Studio Code

Visual Studio Code — это эффективный и облегченный редактор исходного кода, который работает на компьютере. Visual Studio Code доступен для Windows, macOS и Linux.

Хотя Visual Studio Code не поставляется с автоматическим установщиком .NET, таким как Visual Studio, добавление поддержки .NET не вызывает затруднений.

Установка с помощью функции автоматизации Bash

Сценарии dotnet-install используются для автоматизации установок среды выполнения и их осуществления без прав администратора. Вы можете скачать сценарий со страницы справочника по сценариям dotnet-install.

Этот сценарий по умолчанию устанавливает последнюю версию с долгосрочной поддержкой (LTS), которой сейчас является .NET Core 3.1. Вы можете выбрать конкретный выпуск, указав параметр current . Включите параметр runtime для установки среды выполнения. В противном случае сценарий устанавливает пакет SDK.

Приведенная выше команда устанавливает среду выполнения ASP.NET Core для максимальной совместимости. Среда выполнения ASP.NET Core также включает в себя стандартную среду выполнения .NET.

Docker

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

.NET можно выполнять в контейнере Docker. Официальные образы Docker для .NET публикуются в реестре контейнеров Microsoft (MCR), и доступ к ним можно получить в репозитории Microsoft .NET Core Docker Hub. Каждый репозиторий содержит рабочие образы для разных сочетаний .NET (пакета SDK или среды выполнения) и операционной системы.

Корпорация Майкрософт предоставляет образы, которые предназначены для конкретных сценариев. Например репозиторий ASP.NET Core содержит образы, которые предназначены для запуска приложений ASP.NET Core в рабочей среде.

Дополнительные сведения об использовании .NET Core в контейнере Docker см. в статьях Введение в .NET и Docker и Примеры.

Источник

Xcode 11 и XCFrameworks: новый формат упаковки фреймворков

В жизни многих компаний, которые имеют и развивают свой стек библиотек и компонентов, наступает момент, когда объёмы этого стека становится сложно поддерживать.

В случае разработки под платформу iOS, да и в целом, экосистему Apple, есть два варианта подключать библиотеки в качестве зависимостей:

1. Собирать их каждый раз при сборке приложения.
2. Собирать их заранее, используя уже собранные зависимости.

При выборе второго подхода становится логичным использовать CI/CD системы для сборки библиотек в готовые к употреблению артефакты.

Однако, необходимость собирать библиотеки под несколько платформ или архитектур процессора в экосистеме Apple, зачастую, требует проводить не всегда тривиальные операции, как при сборке библиотеки, так и конечного продукта, который её использует.

На этом фоне, было сложно не заметить и крайне интересно изучить, одно из нововведений от Apple, представленное на WWDC 2019 в рамках презентации Binary Frameworks in Swift — формат упаковки фреймворков — XCFramework.

XCFramework имеет несколько преимуществ, в сравнении с устоявшимися подходами:

1. Упаковка зависимостей под все целевые платформы и архитектуры в единый bundle из коробки.
2. Подключение bundle в формате XCFramework, как единой зависимости для всех целевых платформ и архитектур.
3. Отсутствие необходимости в сборке fat/universal фреймворка.
4. Нет необходимости избавляться от x86_64 слайсов (slice) перед загрузкой конечных приложений в AppStore.

В этой статье мы расскажем, зачем был внедрён этот новый формат, что он из себя представляет, а также, что он даёт разработчику.

Как появился новый формат

Ранее компанией Apple был выпущен менеджер зависимостей Swift Package Manager.
Суть в том, что Swift PM позволяет выполнять поставку библиотек в форме открытого исходного кода с описанием зависимостей.

С позиции разработчика, поставляющего библиотеку, хотелось бы выделить два аспекта Swift PM.

• Очевидный минус — по тем или иным причинам, не все поставщики библиотек хотели бы открывать их исходный код потребителям.
• Очевидный плюс — при компиляции зависимостей из исходников мы избавляемся от необходимости соблюдать бинарную совместимость библиотек.

XCFramework Apple предлагает, как новый бинарный формат упаковки библиотек, рассматривая его как альтернативу Swift Packages.

Этот формат, как и возможность подключения собранной в XCFramework библиотеки, доступен, начиная с Xcode 11 и его beta-версий.

Что из себя представляет XCFramework

По своей сути, XCFramework — новый способ упаковки и поставки библиотек, в их различных вариантах.

Кроме прочего, новый формат также позволяет производить и упаковку статических библиотек вместе с их заголовочными файлами, в том числе и написанных на С/Objective-C.

Рассмотрим формат несколько подробнее.

Упаковка зависимостей под все целевые платформы и архитектуры в единый bundle из коробки

Все сборки библиотеки под каждую из целевых платформ и архитектур теперь могут быть упакованы в единый bundle с расширением .xcframework.
Однако, для этого, на данный момент времени, приходится использовать скрипты для вызова команды xcodebuild с новым для Xcode 11 ключом -create-xcframework .

Процесс сборки и упаковки рассмотрим далее.

Подключение bundle в формате XCFramework, как единой зависимости для всех целевых платформ и архитектур

Поскольку bundle .xcframework содержит все необходимые варианты сборки зависимости, нам не нужно заботиться о его архитектуре и целевой платформе.

В Xcode 11 библиотека, упакованная в .xcframework подключается точно также, как и обычный .framework.
Говоря конкретнее, этого можно добиться следующими способами в настройках target’а:

• добавляя .xcframework в раздел «Frameworks And Libraries» на вкладке «General»
• добавляя .xcframework в «Link Binary With Libraries» на вкладке «Build Phases»

Отсутствие необходимости в сборке fat/universal фреймворка

Ранее для поддержки в подключаемой библиотеке нескольких платформ и нескольких архитектур приходилось подготавливать так называемые fat или universal фреймворки.
Производилось это с помощью команды lipo для сшития всех вариантов собранного фреймворка в единый толстый бинарник.

Подробнее с этим можно ознакомиться, к примеру, в следующих статьях:

Нет необходимости избавляться от x86_64 слайсов (slice) перед загрузкой конечных приложений в AppStore

Обычно такой слайс используется для обеспечения работы библиотек в симуляторе iOS.
При попытке загрузить приложение с зависимостями, содержащими x86_64 слайс в AppStore можно столкнуться с небезызвестной ошибкой ITMS-90087.

Создание и упаковка XCFramework: теория

В упомянутой ранее презентации, описаны несколько шагов, которые требуются для сборки и упаковки библиотеки в формате XCFramework:

Подготовка проекта

Для начала во всех target’ах проекта, которые отвечают за сборку библиотеки под целевые платформы, нужно включить новую для Xcode 11 настройку — «Build Libraries for Distribution».

Сборка проекта под целевые платформы и архитектуры

Далее нам предстоит собрать все таргеты под целевые платформы и архитектуры.
Рассмотрим примеры вызова команд на примере определённой конфигурации проекта.

Допустим, что в проекте у нас есть две схемы «XCFrameworkExample-iOS» и «XCFramework-macOS».

Также в проекте есть два target’а, которые собирают библиотеку под iOS и под macOS.

Для сборки всех требуемых конфигураций библиотеки нам потребуется собрать оба target’а, используя соответствующие им схемы.
Однако, для iOS нам потребуется две сборки: одна под конечные устройства (ARM), а другая под симулятор (x86_64).

Итого нам потребуется собрать 3 фреймворка.

Для этого можно воспользоваться командой xcodebuild :

В итоге у нас получилось 3 собранных фреймворка, которые далее мы будем упаковывать в контейнер .xcframework.

Упаковка собранных .framework в .xcframework

Сделать это можно следующей командой:

Здесь может быть множество указаний параметра -framework , которые указывают на все сборки .framework, которые требуется вложить в контейнер .xcframework.

Подготовка проекта библиотеки для будущей сборки и упаковки XCFramework

TL;DR: готовый проект можно скачать в репозитории на Github.

В качестве примера реализуем библиотеку, которая будет доступна под две платформы: iOS и macOS.
Воспользуемся упомянутой в предыдущем разделе статьи конфигурацией проекта: две схемы и два соответствующих им Framework target’а для платформ iOS и macOS.

Сама же библиотека будет предоставлять нам простенький extension для String? ( Optional where Wrapped == String ), с единственным свойством.

Назовём это свойство isNilOrEmpty и, как следует из названия, оно позволит нам узнать, когда внутри String? отсутствует значение или хранимая внутри строка является пустой.

Код можно реализовать следующим образом:

Приступим непосредственно к созданию и конфигурации проекта.

Для начала нам нужно создать проект типа «Framework» под одну из двух целевых платформ на ваш выбор: iOS или macOS.

Сделать это в Xcode можно через пункт меню «File» => «New» => «Project», либо сочетанием клавиш ⇧ + ⌘ + N (по умолчанию).

Далее наверху диалога выбираем нужную платформу (iOS или macOS), выбираем тип проекта Framework и переходим далее по кнопке «Next».

На следующем экране нам нужно задать имя проекта в поле «Product Name».

Как вариант можно использовать «базовое» имя проекта, в упомянутой ранее конфигурации это «XCFrameworkExample».

В дальнейшем, при конфигурации проекта к базовому имени, использованному в имени target’ов мы добавим суффиксы, обозначающие платформы.

После этого требуется создать ещё один Target типа «Framework» в проекте под другую из перечисленных платформ (кроме той, под которую проект был создан изначально).

Для этого можно воспользоваться пунктом меню «File» => «New» => «Target».

Далее выбираем в диалоге другую (относительно выбранной в пункте 1) из двух платформ, после чего снова выбираем тип проекта «Framework».

Для поля «Product Name» мы можем сразу использовать название с суффиксом платформы, для которой мы в данном пункте добавляем target. Так, если платформа — это macOS, то имя может быть «XCFrameworkExample-macOS» (%base_name%-%platform%).

Настроим таргеты и схемы, чтобы их было проще отличать.

Для начала переименуем наши схемы и привязанные к ним target’ы таким образом, чтобы их имена отображали платформы, например так:

Далее добавляем в проект .swift файл с кодом нашего extension’а для String?

Добавим в проект новый .swift файл с именем «Optional.swift».
И в сам файл помещаем ранее упомянутый extension для Optional .

Важно не забыть добавить файл с кодом к обеим target’ам.

Теперь у нас есть проект, который мы можем собрать в XCFramework используя команды из предыдущего этапа.

Процесс сборки и упаковки библиотеки в формат .xcframework

Для сборки библиотеки и упаковки её в формат .xcframework на данном этапе можно воспользоваться bash-скриптом в отдельном файле. К тому же, это позволит в будущем использовать эти наработки для интеграции решения в CI/CD системы.

Скрипт выглядит до безобразия просто и, по факту, сводит воедино ранее упомянутые команды для сборки:

Содержимое .xcframework

В результате работы скрипта cборки из предыдущего пункта статьи, мы получаем заветный bundle .xcframework, который можно добавлять в проект.

Если мы заглянем внутрь этого bundle, который, как и .framework, является по сути простой папкой, то увидим следующую структуру:

Здесь мы видим, что внутри .xcframework лежат сборки в формате .framework, разбитые по платформам и архитектурам. Также для описания содержимого bundle .xcframework, внутри имеется файл Info.plist.

Можно заметить, что для ключа «CFBundlePackageType», в отличии от формата .framework используется новое значение «XFWK», а не «FMWK».

Итоги

Итак, формат упаковки библиотек в XCFramework есть ни что иное, как обычный контейнер для библиотек собираемых в формате .framework.

Однако, такой формат позволяет отдельно хранить и независимо использовать каждую из архитектур и платформ, представленных внутри. Это избавляет от ряда проблем, присущих широко распространённому подходу со сборкой fat/universal фреймворков.

Как бы то ни было, на данный момент, есть немаловажный нюанс, касающийся вопроса использования XCFramework в реальных проектах — управление зависимостями, которое в формате XCFramework компанией Apple не реализовано.

Для этих целей привычно используются Swift PM, Carthage, CocoaPods и прочие системы управления зависимостями и их сборки. Поэтому неудивительно, что поддержка нового формата уже находится на стадии реализации именно в проектах CocoaPods и Carthage.

Источник