Что такое net framework sdk

Обновлено: 07.07.2024

Пример 1

Для начала создадим и запустим консольное приложение Hello World (я буду использовать PowerShell для Windows, но в Bash для macOS или Linux все делается аналогично).

Команда dotnet new делает то же самое, что элемент меню File – New Project в Visual Studio. С её помощью можно создавать проекты различных типов. Используйте команду dotnet new , чтобы вывести список предустановленных шаблонов.

Давайте переместим часть логики в библиотеку классов. Для этого в дополнение к проекту hello создадим проект библиотеки классов.

Переименуем файл Class1.cs в HelloWorld.cs .

Чтобы использовать класс HelloWorld , нужно добавить в приложение hello ссылку на библиотеку, в которой содержится логика. Для этого можно изменить файл проекта или воспользоваться командой dotnet add reference .

Теперь изменим файл Program.cs так, чтобы в нем использовался класс HelloWorld .

Обновление файла Program.cs для дальнейшего использования класса HelloWorld:

Чтобы собрать и запустить приложение, введите команду dotnet run .

В командной строке также можно создавать тесты. Этот CLI поддерживает MSTest , а также популярную платформу xUnit . Давайте для примера воспользуемся xUnit.

Чтобы добавить тест, измените содержимое файла UnitTest1.cs , как показано ниже.

Добавление теста в файл UnitTest1.cs:

Теперь можно запустить тесты с помощью команды dotnet test .

Пример 2

Чтобы запустить тестовый веб-сервер, вновь введите команду dotnet run .

Откройте в браузере URL-адрес, который был выведен в консоли (это должен быть адрес localhost:5000).

Сейчас структура вашего проекта должна соответствовать вот такой структуре.

Структура созданного проекта:

Чтобы упростить редактирование файлов в Visual Studio, создадим файл решения *.SIN и добавим в него все проекты.

BCL — это набор базовых API, не зависящих от инфраструктур пользовательского интерфейса и моделей приложений. В него входят простые типы, файловый ввод-вывод, сетевые API, API сериализации, XML и другое.

Пример 3

Сравним его с файлом проекта консольного приложения hello.

Пример 4

Эта библиотека поддерживает дополнительные типы коллекций, которых нет в BCL. Один из них — тип Bag , не гарантирующий какого-либо порядка элементов. Изменим наше приложение hello так, чтобы в нем использовался этот тип.

Пример приложения с использованием PowerCollections:

Если вы запустите программу, то увидите следующее:

Компилятор выкинул warning но программа отработала!

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

Заключение

Доступные пакеты SDK

Доступны следующие пакеты SDK:

Можно также создать собственный пакет SDK и распространять его с помощью NuGet.

Файлы проекта

Чтобы указать пакет SDK, который содержится в NuGet, добавьте версию в конец имени или укажите имя и версию в файле global.json.

Другим способом указания пакета SDK является элемент Sdk верхнего уровня.

Предварительная обработка файла проекта

Увидеть полностью развернутый проект так, как он отображается в MSBuild, можно после включения пакета SDK и его целевых объектов с помощью команды dotnet msbuild -preprocess . Включите параметр preprocess в команду dotnet msbuild , чтобы просмотреть сведения об импортированных файлах, их источниках, вкладе в сборку без фактического создания проекта.

dotnet msbuild -property:TargetFramework=netcoreapp2.0 -preprocess:output.xml

Включения и исключения по умолчанию

Папки ./bin и ./obj , которые представлены свойствами MSBuild $(BaseOutputPath) и $(BaseIntermediateOutputPath) , исключаются из стандартных масок исключения по умолчанию. Исключения представлены свойством DefaultItemExcludes.

Ошибки сборки

Чтобы устранить такую проблему, выполните любое из следующих действий:

Удалите явно заданные элементы Compile , EmbeddedResource или None , которые совпадают с неявно заданными параметрами из предыдущей таблицы.

Присвойте свойству EnableDefaultItems значение false , чтобы отключить все неявные включения файлов:

Если вы хотите указать файлы, которые нужно публиковать вместе с приложением, для этого можно по-прежнему использовать привычные механизмы MSBuild (например, элемент Content ).

Выборочно отключите только стандартные маски Compile , EmbeddedResource или None , присвоив свойствам EnableDefaultCompileItems, EnableDefaultEmbeddedResourceItems или EnableDefaultNoneItems значение false :

Если вы отключите только стандартные маски Compile , обозреватель решений в Visual Studio будет по-прежнему отображать элементы *.cs в составе проекта, включая их в виде элементов None . Чтобы отключить неявную стандартную маску None , задайте свойству EnableDefaultNoneItems значение false .

Неявные директивы using

Неявные директивы global using добавляются для проектов, которые используют один из следующих пакетов SDK:

Директива global using добавляется для каждого пространства имен в наборе стандартных пространств имен, в зависимости от конкретного пакета SDK для проекта. Эти пространства имен по умолчанию показаны в следующей таблице.

Неявные ссылки на пакет

При необходимости можно отключить неявные ссылки на пакеты с помощью свойства DisableImplicitFrameworkReferences и добавить явные ссылки только на необходимые платформы или пакеты.

События сборки

Для проектов в стиле пакета SDK используйте целевой объект MSBuild с именем PreBuild или PostBuild и задайте свойство BeforeTargets для PreBuild или свойство AfterTargets для PostBuild .

Для целевых объектов MSBuild можно использовать любые имена. Однако интегрированная среда разработки Visual Studio распознает целевые объекты PreBuild и PostBuild , поэтому с помощью этих имен можно изменять команды в интегрированной среде разработки.
Свойства PreBuildEvent и PostBuildEvent не рекомендуется использовать в проектах в стиле пакета SDK, поскольку такие макросы, как $(ProjectDir) , не разрешены. Например, приведенный ниже код не поддерживается.

Настройка сборки

Пользовательские целевые объекты

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

Следующий XML-код является фрагментом из файла CPROJ, который указывает команде dotnet pack , что именно нужно упаковать. Элемент <ItemGroup Label="dotnet pack instructions"> помещает файлы целевых объектов в папку build в пакете. Элемент <Target Name="CollectRuntimeOutputs" BeforeTargets="_GetPackageFiles"> помещает сборки и файлы JSON в папку build.

Чтобы использовать пользовательский целевой объект в проекте, добавьте элемент PackageReference , указывающий на пакет и его версию. В отличие от средств пакет пользовательских целевых объектов входит в замыкание зависимостей исходного проекта.

Вы можете настроить способ использования пользовательского целевого объекта. Так как это целевой объект MSBuild, он может зависеть от заданного целевого объекта, запускаться после другого целевого объекта или быть вызван вручную с помощью команды dotnet msbuild -t:<target-name> . Однако для удобства пользователей можно объединить средства для отдельных проектов и пользовательские целевые объекты. В этом сценарии средство для отдельного проекта принимает необходимые параметры и преобразует их в требуемый вызов dotnet msbuild , который выполняет целевой объект. Пример подобного типа синергии можно увидеть в репозитории примеров хакатона MVP Summit 2016 в проекте dotnet-packer .

Текст объемный и рассчитан на:

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

0. Pay-for-Play

BCL располагается в GAC, откуда приложения загружают необходимые для работы зависимости.

Примеры компонентов, которые поставляются через NuGet:

Этот подход называется «pay-for-play»; другими словами, приложения загружают только ту функциональность, которая им необходима, но каждая такая функциональность содержится в отдельной сборке.

1. FDD vs SCD

Portable (Framework-dependent deployment — FDD)
Standalone (Self-contained deployment — SCD)

В Standalone (SCD)-приложении все компоненты для выполнения (CoreCLR, CoreFX), а также сторонние библиотеки, то есть абсолютно все зависимости, поставляются вместе с самим приложением (чаще всего в одной папке).

Важно понимать, что Standalone-приложение привязано к определенной ОС и архитектуре (например, Windows 7 x64 или OSX 10.12 x64). Такой идентификатор называется Runtime identifier (RID). Для каждой ОС/архитектуры существует своя версия библиотеки Core CLR (и прочих нативных компонентов), поэтому для Standalone-приложений на этапе компиляции в свойстве RuntimeIdentifier нужно указывать параметры целевой системы (RID).

Файлы фреймворка(-ов) хранятся в папке C:\Program Files\dotnet\shared.

Можно установить несколько версий фреймворка:

Для выполнения Portable-приложения необходимо запустить хост-процесс dotnet.exe и передать ему в качестве аргумента путь к управляемой сборке.

«C:\Program Files\dotnet» добавляется к значению переменной среды PATH, благодаря чему Portable-приложения теперь могут запускаться из командной строки:

Этот файл является обязательным для Portable-приложений.

Уменьшение количества файлов объясняется тем, что в Core FX 1.0 отсутствовали многие библиотеки, поэтому они шли в составе приложения, как обычные зависимости. В Core FX 2.0 эти сборки были добавлены, поэтому они больше не поставляются с приложением, а берутся из папки фреймворка.

Наблюдается картина, противоположная Portable-приложениям — чем больше становится Core FX, тем больше файлов поставляется с приложением.

Рекомендации по выбору типа развертывания

5. Runtime Configuration Files

dotnet.exe ([AppName].exe) использует файл [AppName].deps.json для определения абсолютных путей всех зависимостей приложения при его запуске.

Структура [AppName].deps.json:

Секция targets определяет платформу и дерево зависимостей для нее в формате

[ID зависимости (пакета)]/[версия]: dependencies: < список зависимостей (пакетов) данного пакета >,
относительные пути к управляемым и нативным файлам данного пакета
>

Рассмотрим подробнее содержимое файла deps.json Standalone-приложения:

В свойстве dependencies перечислены зависимости (пакеты) конкретного пакета.
Свойство runtimeTargets используется в deps-файле Portable-приложения и определяет пути файлов библиотек для конкретного RID. Такие RID-specific библиотеки поставляются вместе с Portable-приложением в папке runtimes.

Свойства runtime и native содержат относительные пути управляемых (managed) и нативных библиотек соответственно. Свойство resources содержит относительные пути и локали локализованных сборок-ресурсов.

Пути относительны к NuGet package cache, а не deps-файлу.

Добавить сторонний deps-файл можно передав значение аргумента --additional-deps или переменную среды DOTNET_ADDITIONAL_DEPS.

Такая возможность доступна только для Portable приложений.

Когда dotnet.exe (MyApp.exe) определяет пути зависимостей приложения, для каждой отдельной библиотеки составляется список из runtime- и native-путей.

6.1. Запуск приложения
выполняется при помощи мультплексора (muxer) из командной строки (одинаково на любой ОС).

6.2. [corehost] Поиск и загрузка Framework Resolver (hostfxr.dll)
На этом этапе dotnet.exe идет в папку [own directory]/host/fxr/. Для Portable-приложений эта библиотека расположена в общей папке C:\Program Files\dotnet\host\fxr\[FXR version]\hostfxr.dll. Если версий будет несколько, dotnet.exe будет всегда использовать последнюю.

После загрузки hostfxr.dll (Framework Resolver) процесс запуска переходит в рамки этой библиотеки.

6.3. [hostfxr] Определение режима выполнения (standalone, muxer, split/FX)
Первая задача hostfxr — определить режим, в котором будет работать хост процесс и таким образом тип приложения — Portable (FDD) или Standalone (SCD). В Portable (FDD)-режиме он также определяет: это запускаемое приложение или команда SDK.

— если среди аргументов есть такой, значение которого оканчивается на .dll или .exe — процесс запуска продолжится в режиме выполнение указанного файла. Если такого аргумента нет, управление будет передано SDK. Для этого из папки [own directory]\sdk\[version] (если такая существует) будет запущен dotnet.dll (как Portable приложение), и этой сборке будут переданы аргументы текущего хост процесса.

Алгоритм проверки очень простой — если в папке, откуда был запущен мультиплексор [AppName].exe (в нашем случае dotnet.exe), отсутствует coreclr.dll или [AppName].dll, то приложение Portable. Если один из этих двух файлов существует, то далее идет проверка — приложение Portable (split/FX) или Standalone. Если существует [AppName].dll, то приложение Standalone, иначе — Portable (split/FX).

Запуск Portable-приложения может также осуществляться в так называемом Exec mode.
Для этого команда запуска первым аргументом должна содержать exec C:\> dotnet exec . .

При запуске в таком режиме можно явно указать пути к файлам конфигурации:
--depsfile <PАTH>
--runtimeconfig <PАTH>
которые будут использованы вместо файлов в папке приложения.

На текущем этапе hostfxr определяет (по данным файла конфигурации), является ли приложение Portable или Standalone.

При выборе версии учитывается параметр Roll Forward On No Candidate Fx, который указывает строгость соответствия заданной версии и имеющихся на машине.

6.5. [hostfxr] Поиск и загрузка hostpolicy.dll
На текущем этапе всё готово для определения путей runtime-компонентов. Этой задачей занимается библиотека hostpolicy.dll, которая называется Host library.

Если файл не был найден на предыдущем этапе, hostpolicy.dll будет найдено в папке фреймворка.

Как только опеределена hostpolicy.dll, hostfxr загружает эту библиотеку и передает ей управление.

6.6. [hostpolicy] Определение списка зависимостей
Библиотека hostpolicy.dll отвечает за определение абсолютных путей всех зависимостей приложения.

Прежде всего hostpolicy создаст компонент под названием Dependencies Resolver, который в свою очередь загрузит два deps-файла — файл фреймворка и файл приложения.

Сперва загружается список из deps-файл фреймворка, где будут определены такие зависимости, как CoreCLR и библиотеки CoreFX. Затем список из deps-файла приложения, в котором указаны сборки нашего приложения и их зависимости.

Для каждого deps-файла Dependency Resolver составляет список всех зависимостей для указанной runtimeTarget.

Для каждого пакета сначала составляется список файлов из всех секций runtimeTargets (RID specific зависимости), далее — список всех файлов из секций native и runtime. Такой объединенный список относительных путей всех зависимостей в условном формате
ID пакета — RID — тип asset'а (runtime, native) — пути к файлам называется Target assets.

После того, как были составлены эти два списка файлов зависимостей (RID и не RID), выполняется процесс под названием Reconciling libraries with targets (согласования). Он заключается в том, что для каждого пакета из секции libraries проверяется, существует ли RID specific-файлы, которые должны переопределить обычные.

6.7. [hostpolicy] Определение путей TPA, Core CLR и CLR Jit
Далее Dependency resolver составляет список абсолютных путей файлов управляемых сборок — зависимостей приложения. Этот список называется TPA (Trusted Platform Assemblies) и передается Core CLR для настройки AppDomain. Также составляется список абсолютных путей директорий, в которых находятся остальных файлы зависимостей (кроме coreclr, corejit).

Определение абсолютных путей управляемых сборок происходит путем поиска файлов в Probe paths (путей зондирования). По умолчанию их два — папка фреймворка и папка приложения, и они основаны на расположении deps-файлов. Также можно добавить дополнительные пути:

1) передав аргумент --additionalprobingpath, например
--additionalprobingpath %UserProfile%\\.nuget\\packages

В папке фреймворка и приложения наличие файла проверятся (при условии, что он был указан в соответствующем deps-файле) без учета относительного пути, в остальных директориях с учетом относительно пути, потому что эти директории рассматриваются как кеш NuGet-пакета.

папка приложения;
папка фреймворка
Probe paths

После составления списка TPA, определяются пути CoreCLR и CLRJit.

При отсутствии deps-файла приложения, dotnet.exe вначале попытается найти эти библиотеки в [app directory]\lib\. При обычном выполнении пути берутся из папки фреймворка (отбросив относительный путь и взяв только имя файла).

Устанавливаются следующие настройки CoreCLR:

TRUSTED_PLATFORM_ASSEMBLIES — список обсолютных путей всех управляемых библиотек приложения.
NATIVE_DLL_SEARCH_DIRECTORIES — абсолютные пути директорий, где найдены нативные зависимости.
PLATFORM_RESOURCE_ROOTS — абсолютные пути директорий, где найдены зависимости-ресурсы
AppDomainCompatSwitch — константа «UseLatestBehaviorWhenTFMNotSpecified».
APP_CONTEXT_BASE_DIRECTORY — папка приложения.
APP_CONTEXT_DEPS_FILES — абсолютные пути deps-файлов приложения и фреймворка.
FX_DEPS_FILE — абсолютный путь deps-файла фреймворка.
PROBING_DIRECTORIES — дополнительные пути зондирования (если они были указаны).

Процесс запуска Standalone-приложения отличается от Portable только начальным этапом, а также местоположением компонентов, которые по умолчанию должны располагаться в папке приложения.

7.2. Процесс запуска
происходит так же, как у Portable-приложения, за исключением того, что существует только один deps-файл и все зависимости ищутся в папке приложения или по указанным --additionalprobepaths.

Почему так происходит? Что это такое и зачем нужен NET Framework ?

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

Но есть одна проблема — языки программирования довольно примитивны. С их помощью можно легко выполнять простые действия вроде сложения и умножения. А всё остальное требует долгой и усердной работы. Хотите вывести текст или изображения на экран? Тогда придётся написать много кода, используя самые простые элементы языка.

Как установить Microsoft NET Framework

На момент написания статьи самая свежая версия — Microsoft NET Framework 4,7 . Именно её мы и будем устанавливать:

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

Перед установкой — Microsoft Net Framework можно установить на Windows 10 , Windows 8.1 и Windows 7 SP1 как на 32-битные, так и на 64-битные системы. Чтобы установка прошла без ошибок, Microsoft рекомендует иметь на жестком диске минимум 2.5 ГБ свободного пространства.

Microsoft предлагает два вида установщиков: веб-установщик и автономный установщик. Веб-установщик весит меньше 2 МБ, и скачивает все необходимые компоненты во время инсталляции. Поэтому вам потребуется стабильное соединение с интернетом.

Автономный установщик весит около 60 МБ, и не требует доступа к интернету во время инсталляции.

Оба установщика содержат одинаковые версии NET Framework , но мы предпочитаем использовать автономный установщик. Он надёжнее, и всегда будет под рукой, если потребуется переустановить NET Framework . После скачивания процесс установки не должен вызвать затруднений — просто следуйте инструкциям, появляющимся на экране. И тогда вы быстрее поймете, зачем нужен NET Framework 4 .

Обратите внимание, что версия 4.7 — это выполняемое обновление версий 4 , 4.5 , 4.5.1 , 4.5.2 , 4.6 , 4.6.1 и 4.6.2 . Поэтому не удаляйте предыдущие версии после установки. NET Framework 3.5 SP1 и более старые версии устанавливаются отдельно.

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

Ещё кое-что о Microsoft Net Framework

Еще одна причина, зачем нужен NET Framework . Несколько лет назад Microsoft открыла исходный код NET Framework , позволив всем желающим вносить свой вклад в разработку платформы. В результате Microsoft стала самой активной организацией на GitHub .

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

Пожалуйста, оставьте ваши отзывы по текущей теме материала. За комментарии, дизлайки, подписки, лайки, отклики огромное вам спасибо!

Так в чем же разница? Является ли это в первую очередь маркетинговой игрой семантики или существуют реальные различия в том, как разработчики должны взаимодействовать с программным обеспечением (и наоборот, как разработчики могут ожидать, что программное обеспечение будет вести себя)? Ожидается ли, что один будет на более высоком или низком уровне, чем другой, и т. Д.?

РЕДАКТИРОВАТЬ: Этот вопрос относится к SDK и фреймворкам в целом, а не только к двум, упомянутым выше.

Таким образом, вы можете разработать Framework, состоящий исключительно из библиотек, но если вы назовете его SDK, вы должны будете предложить что-то для поддержки разработки.

Я просто скопирую из Википедии:

Библиотека - это набор подпрограмм или классов, используемых для разработки программного обеспечения. Библиотеки содержат код и данные, которые предоставляют услуги независимым программам. Это позволяет совместно использовать код и данные и изменять их по модульному принципу.

Программная среда в компьютерном программировании - это абстракция, в которой общий код, обеспечивающий общие функциональные возможности, может выборочно переопределяться или специализироваться пользовательским кодом, обеспечивающим определенные функциональные возможности. Фреймворки аналогичны программным библиотекам в том, что они представляют собой повторно используемые абстракции кода, заключенного в четко определенный API. Однако, в отличие от библиотек, общий поток управления программой определяется не самим вызывающим, а структурой. Эта инверсия управления является отличительной чертой программных платформ.

Набор для разработки программного обеспечения (SDK или «devkit») обычно представляет собой набор инструментов для разработки, который позволяет разработчику программного обеспечения создавать приложения для определенного пакета программного обеспечения, структуры программного обеспечения, аппаратной платформы, компьютерной системы, игровой консоли, операционной системы. или аналогичная платформа. Это может быть что-то такое же простое, как интерфейс прикладного программирования в виде некоторых файлов для взаимодействия с конкретным языком программирования или сложное аппаратное обеспечение для связи с определенной встроенной системой. Общие инструменты включают средства отладки и другие утилиты, часто представленные в IDE. SDK также часто включают в себя пример кода и сопроводительные технические примечания или другую сопроводительную документацию, чтобы помочь прояснить моменты из основного справочного материала.

В двух словах, разница в следующем:

Вы вызываете функции SDK.
Платформа вызывает ваши функции.

SDK - это как набор инструментов с множеством инструментов, и вы выбираете, какие из них использовать и как. У вас есть контроль, но и много решений. Это довольно низкий уровень.

Фреймворк принимает множество решений за вас, поэтому вам не нужно изобретать велосипед; Это скорее подход "заполнить пробелы". Меньше свободы, но вы экономите много времени и, возможно, избегаете некоторых ошибок.

Я был ведущим в Zend Framework в своей версии 1.0. Мы часто получали комментарии о том, что это не «фреймворк» в том смысле, в котором ожидали разработчики - они сказали, что это скорее библиотека классов.

Они ожидали, что инфраструктура больше похожа на набор классов, которые должны использоваться вместе, чтобы они работали. Фреймворк также может включать в себя набор соглашений о кодировании, которые помогут вам организовать ваш код определенным образом. Также фреймворк может налагать соглашения об именах для ваших классов и объектов базы данных. И, наконец, инструменты для генерации кода.

Zend Framework был разработан для слабой связи, поэтому вы можете использовать любой из классов, если хотите. Это наложило несколько соглашений на ваш код или вашу базу данных. И мы собирались разработать генераторы кода, но еще не реализовали их.

Но я все еще чувствовал, что Zend Framework квалифицируется как фреймворк, а не как SDK, еще одним способом: фреймворк расширяемый . Он спроектирован как набор объектно-ориентированных базовых классов, и предполагается, что разработчики либо extend этих классов, либо пишут простые плагины в классах, чтобы добавить функциональность.

Традиционный SDK не расширяемый . Вы просто вызываете методы API в предоставленных классах, они делают то, что делают, и вы работаете с результатом. Любая настройка заключается в том, как вы используете API и как вы используете результаты.

Microsoft SDK может использоваться разработчиком для создания своих программ. Конечным пользователям обычно это не нужно.

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

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

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

В одном сравнении вы могли бы сказать:
Библиотека -> Framework -> SDK
Framework состоит из нескольких библиотек, а также некоторых инструментов (компиляторов и т. Д.) И не ориентирован на конкретную платформу. Для платформы может быть разработано несколько платформ, каждая из которых предназначена для разных целей. SDK предлагает вам фреймворки и все остальное, что вам нужно для разработки программного обеспечения для конкретной платформы.

Читайте также: