Dotnet microsoft что это
Free. Cross-platform. Open source.
A developer platform for building all your apps.
Supported on Windows, Linux, and macOS
Build web apps and services for Windows, Linux, macOS, and Docker.
Mobile
Use a single codebase to build native mobile apps for iOS, Android, and Windows.
Desktop
Create beautiful and compelling desktop apps for Windows and macOS.
Microservices
Create independently deployable microservices that run on Docker containers.
Cloud
Consume existing cloud services, or create and deploy your own.
Machine Learning
Add vision algorithms, speech processing, predictive models, and more to your apps.
Game Development
Develop 2D and 3D games for the most popular desktops, phones, and consoles.
Internet of Things
Make IoT apps, with native support for the Raspberry Pi and other single-board computers.
Languages
One Platform
.NET 101 Video Series
Thank You to All the Contributors
.NET is open source and we are very thankful for the many contributions it receives from the community.
Ready to Get Started?
.NET Standard
| .NET Standard | 1.0 | 1.1 | 1.2 | 1.3 | 1.4 | 1.5 | 1.6 | 2.0 | 2.1 |
|---|---|---|---|---|---|---|---|---|---|
| .NET | 5.0 | 5.0 | 5.0 | 5.0 | 5.0 | 5.0 | 5.0 | 5.0 | 5.0 |
| .NET Core | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 2.0 | 3.0 |
| .NET Framework 1 | 4.5 | 4.5 | 4.5.1 | 4.6 | 4.6.1 | 4.6.1 2 | 4.6.1 2 | 4.6.1 2 | N/A 3 |
| Mono | 4.6 | 4.6 | 4.6 | 4.6 | 4.6 | 4.6 | 4.6 | 5,4 | 6.4 |
| Xamarin.iOS | 10.0 | 10.0 | 10.0 | 10.0 | 10.0 | 10.0 | 10.0 | 10.14 | 12.16 |
| Xamarin.Mac | 3.0 | 3.0 | 3.0 | 3.0 | 3.0 | 3.0 | 3.0 | 3.8 | 5.16 |
| Xamarin.Android | 7.0 | 7.0 | 7.0 | 7.0 | 7.0 | 7.0 | 7.0 | 8.0 | 10.0 |
| Универсальная платформа Windows | 10.0 | 10.0 | 10.0 | 10.0 | 10.0 | 10.0.16299 | 10.0.16299 | 10.0.16299 | TBD |
| Unity | 2018.1 | 2018.1 | 2018.1 | 2018.1 | 2018.1 | 2018.1 | 2018.1 | 2018.1 | 2021.2 |
Существует два основных правила управления версиями.
Спецификация
Официальные артефакты
Доступны производные артефакты, упрощающие чтение и реализующие определенные сценарии для разработчика (например, использование компилятора).
Представление пакетов
Управление версиями
Это не отдельная спецификация, а набор API с линейно возрастающими номерами версий. Первая версия стандарта устанавливает базовый набор API. Последующие версии добавляют API и наследуют API, определенные в предыдущих версиях. Не существует установленных процедур для удаления API из стандарта.
Выбор целевой платформы net5.0 или netstandard
Повторно используемые библиотеки
Задержки с добавлением новых API
Сложная система управления версиями
Разделение спецификации API и его реализации приводит к сложному сопоставлению между версиями спецификаций API и их реализаций. Эта видно из приведенной ранее в этой статье таблицы и инструкций по ее интерпретации.
Не поддерживаемые платформой исключения во время выполнения
.NET Standard предоставляет интерфейсы API для конкретных платформ. При этом ваш код может компилироваться без ошибок и выглядеть доступным для переноса на любую платформу, в то время как на самом деле это не так. При запуске на платформе, на которой отсутствует реализация для данного API, во время выполнения будут возникать ошибки.
.NET is an open source developer platform, created by Microsoft, for building many different types of applications.
.NET is a free, cross-platform, open source developer platform for building many different types of applications.
Languages
Cross Platform
One consistent API
Libraries
Application models
Build web apps and services for Windows, Linux, macOS, and Docker.
Mobile
Use a single codebase to build native mobile apps for iOS, Android, and Windows.
Desktop
Create beautiful and compelling desktop apps for Windows and macOS.
Microservices
Create independently deployable microservices that run on Docker containers.
Cloud
Consume existing cloud services, or create and deploy your own.
Machine Learning
Add vision algorithms, speech processing, predictive models, and more to your apps.
Game Development
Develop 2D and 3D games for the most popular desktops, phones, and consoles.
Internet of Things
Make IoT apps, with native support for the Raspberry Pi and other single-board computers.
Active community and open-source
Get quick answers to questions with an active community of developers on Stack Overflow.
Tools
The Visual Studio Marketplace has thousands of editor extensions from Microsoft and others.
Ready to Get Started?
Microsoft NET Framework — что это такое?
Наверное, вы знаете, что основное занятие программистов — написание кода. При этом они используют различные языки программирования, позволяющие сказать компьютеру, что он должен делать:
Но есть одна проблема — языки программирования довольно примитивны. С их помощью можно легко выполнять простые действия вроде сложения и умножения. А всё остальное требует долгой и усердной работы. Хотите вывести текст или изображения на экран? Тогда придётся написать много кода, используя самые простые элементы языка.
Как установить Microsoft NET Framework
Microsoft предлагает два вида установщиков: веб-установщик и автономный установщик. Веб-установщик весит меньше 2 МБ, и скачивает все необходимые компоненты во время инсталляции. Поэтому вам потребуется стабильное соединение с интернетом.
Автономный установщик весит около 60 МБ, и не требует доступа к интернету во время инсталляции.
.NET Framework 4.7 Веб-установщик
.NET Framework 4.7 Автономный установщик
По умолчанию NET Framework инсталлирует английскую версию независимо от того, какой вы используете установщик. Для локализации нужно скачать соответствующий языковой пакет. На данный момент языковые пакеты для версии 4.7 доступны только в виде автономных установщиков.
Перейдя по ссылке, приведенной ниже, выберите необходимый язык, дождитесь, пока страница перезагрузится, и нажмите « Скачать ».
Ещё кое-что о Microsoft Net Framework
Дайте знать, что вы думаете по данной теме в комментариях. Мы очень благодарим вас за ваши комментарии, лайки, отклики, дизлайки, подписки!
Пожалуйста, оставьте ваши отзывы по текущей теме материала. За комментарии, дизлайки, подписки, лайки, отклики огромное вам спасибо!
.NET – набор вертикалей
Конечно, в самой идее предлагать специализированный набор возможностей, удовлетворяющих определенными потребностям, нет ничего плохого. Это становится проблемой, когда отсутствует системный подход и специализация происходит на каждом слое без учета того, что происходит в соответствующих слоях других вертикалей. Последствием таких решения является набор платформ, которые имеют ряд общих API только потому, что они когда-то начинались из единой базы кода. Со временем, это приводит к росту различий, если только не проводить явные (и дорогие) упражнения для достижения единообразия API.
В какой момент возникает проблема с фрагментацией? Если вы нацелены только на одну вертикаль, то в реальности никакой проблемы нет. Вам предоставлен набор API, оптимизированный именно для вашей вертикали. Проблема проявляет себя, как только вы хотите делать что-то горизонтальное, ориентированное на множество вертикалей. Вот теперь вы задаетесь вопросом о доступности различных API и думаете, как производить блоки кода, которые работали бы на разных целевых вертикалях.
Рождение переносимых библиотек классов (Portable Class Library, PCL)
Изначально не было никакого специального концепта для разделения кода между различными вертикалями. Не было переносимых библиотек классов или разделяемых проектов. Вам буквально было нужно создавать множество проектов, использовать ссылки на файлы и множество #if. Это делало задачу нацеливания кода на множество вертикалей действительно сложной.
К моменту выхода Windows 8 мы пришли к плану, как бороться с этой проблемой. Когда мы проектировали профиль Windows Store, мы ввели новую концепцию для лучшего моделирования подмножества: контракты.
Идея контрактов заключается в том, чтобы предоставить продуманный набор API, подходящих для задач декомпозиции кода. Контракты – это просто сборки, под которые вы можете компилировать свой код. В отличие от обычных сборок, сборки контрактов спроектированы именно под задачи декомпозиции. Мы четко прослеживаем зависимости между контрактами и пишем их так, чтобы они отвечали за что-то одно, а не были свалкой API. Контракты имеют независимую версионность и следуют соответствующим правилам, например, если добавляется новый API, то он будет доступен в сборке с новой версией.
Сегодня мы используем контракты для моделирования API во всех вертикалях. Вертикаль может просто взять и выбрать, какие контракты она будет поддерживать. Важным моментом является то, что вертикаль обязана поддерживать контракт целиком или не поддерживать вовсе. Другими словами, она не может включить в себя подмножество контракта.
Это позволяет говорить о различиях в API между вертикалями уже на уровне сборок в отличие от индивидуальных различиях в API, как это было раньше. Это позволяет нам реализовать механизм библиотек кода, которые нацелены на множество вертикалей. Такие библиотеки сегодня известны как переносимые библиотеки классов (portable class libraries).
Объединение формы API против объединения реализаций
Намного лучше унифицировать реализации: вместо того, чтобы только предоставлять хорошо декомпозированное описание, мы должные подготовить декомпозированную реализацию. Это позволит вертикалям просто использовать одну и ту же реализацию. Сближение вертикалей больше не будет требовать дополнительных действий; оно достигается просто за счет правильного конструирования решения. Конечно все равно будут случаи, в которых необходимы различные реализации. Хороший пример этого – это файловые операции, требующие использования разных технологий в зависимости от окружения. Однако, даже в этом случае намного проще попросить каждую команду, отвечающую за конкретные компонент, подумать, как из API будут работать в разных вертикалях, чем постфактум пытаться предоставить единый набор API поверх. Переносимость – это не есть что-то, что вы можете добавить после. К примеру, наш File API включает поддержку Windows Access Control Lists (ACL), которые не поддерживаются всем окружениями. При дизайне API нужно учитывать такие моменты и, в частности, предоставлять подобную функциональность в отдельных сборках, которые могут отсутствовать на платформах, не поддерживающих ACL.
Фреймворки для всей машины против локальных фреймворков для приложения
Это все очень редкие случаи, но, когда у вас пользовательская база в 1.8 миллиарда машин, быть совместимым с 99.9% по-прежнему означает, что 1.8 миллиона машин затронуто.
Интересно, что во многих случая исправить затронутые приложения требует довольно простых действий. Но проблема в том, что разработчик приложения не всегда доступен в момент поломки. Давайте рассмотрим конкретный пример.
Такой подход в общем-то почти полностью снимает все проблемы, мешающие вам обновиться до свежей версии. Ваши возможности перейти на новую версию ограничены только вашей возможностью выпустить новую версию вашего приложения. Это также означает, что вы контролируете, какая версия библиотеки используется конкретным приложением. Обновления производятся в контексте одного приложения, никак не затрагивая другие приложения на той же машине.
Это позволяет выпускать обновления в гораздо более гибкой манере. NuGet также предлагает возможность попробовать предварительные версии, что позволяет нам выпускать сборки без строгих обещаний относительно работы конктретных API. Такой подход позволяет нам поддерживать процесс, в котором мы предлагаем вам наш свежий взгляд на дизайн сборки – и, если вам не нравится, просто его изменить. Хороший пример это – это неизменяемые коллекции (immutable collections). Бета-период длился порядка 9 месяцев. Мы потратили много времени, пытаясь добиться правильного дизайна прежде, чем выпустить первую версию. Нет необходимости говорить, что финальная версия дизайна библиотеки, — благодаря вашим многочисленным отзывам, — намного лучше, чем начальная.
.NET Core – это модульная реализация, которая может использоваться широким набором вертикалей, начиная с дата-центров и заканчивая сенсорными устройствами, доступная с открытым исходным кодом, и поддерживаемая Microsoft на Windows, Linux и Mac OSX.
NuGet как первоклассный механизм доставки
Для слоя BCL у нас будет прямое соответствие между сборками и пакетами NuGet.
В дальнейшем NuGet-пакеты будут иметь те же имена, что и сборки. К примеру, неизменяемые коллекции перестанут распространяться под именем Microsoft.Bcl.Immutable и вместо этого будут в пакет, называющемся System.Collections.Immutable.
В дополнение, мы решили использовать семантический подход для версионности сборок. Номер версии NuGet-пакета будет согласован с версией сборки.
Согласованность именования и версионности между сборками и пакетами сильно облегчит их поиск. У вас не должно возникнуть вопроса, в каком пакете содержится System.Foo, Version=1.2.3.0 – он находится в пакете System.Foo с версией 1.2.3.
Готов для корпоративного использования
Основа для открытого кода и кросс-платформенности
Из прошлого опыта мы знаем, что успех открытого кода зависит от сообщества вокруг него. Ключевой аспект этого – это открытый и прозрачный процесс разработки, который позволит сообществу участвовать в ревью кода, знакомиться с документам по проектированию и вносить свои изменения в продукт.
Конечно, отдельные компоненты, например, файловая система, требуют отдельной реализации. Модель доставки через NuGet позволяет нам абстрагироваться от этих различий. Мы можем иметь единый NuGet-пакет, предоставляющий различные реализации для каждого из окружений. Однако важный момент тут как раз в том, что это внутренняя кухня реализации компонента. С точки зрения разработчика это единый API, который работает на разных платформах.
Наличие всех трех элементов позволяет нам добиться широкого спектра гибкости и зрелости решений:
Нам кажется, что мы нашли хороший баланс между тем, чтобы заложить основу для будущего, сохраняя при этом хорошую совместимость с существующими стеками. Давайте посмотрим детальнее на часть из этих платформ.
.NET Framework 4.6
Windows Store и Windows Phone
Более детально выбор между двумя подходами описан в статье «Sharing code across platforms».
Итоги
На нас лежит ответственность за продолжение выпуска критичных обновлений безопасности, не требующих работы со стороны разработчиков приложений, даже если затрагиваемые компоненты распространятся эксклюзивно как NuGet-пакеты.
А вот и другие наши статьи по схожей тематике:
