.NET Framework (произносится как « дот нет ») — это фирменная программная среда , разработанная корпорацией Microsoft , которая в основном работает на Microsoft Windows . Она была преобладающей реализацией Common Language Infrastructure (CLI) до тех пор, пока не была заменена кроссплатформенным проектом .NET . Она включает в себя большую библиотеку классов, называемую Framework Class Library (FCL), и обеспечивает языковую совместимость (каждый язык может использовать код, написанный на других языках) на нескольких языках программирования . Программы, написанные для .NET Framework, выполняются в программной среде (в отличие от аппаратной среды), называемой Common Language Runtime (CLR). CLR — это виртуальная машина приложений , которая предоставляет такие службы, как безопасность, управление памятью и обработка исключений . Таким образом, компьютерный код, написанный с использованием .NET Framework, называется « управляемым кодом ». FCL и CLR вместе составляют .NET Framework.
FCL обеспечивает пользовательский интерфейс , доступ к данным , подключение к базам данных , криптографию , разработку веб-приложений , числовые алгоритмы и сетевые коммуникации . Программисты создают программное обеспечение, объединяя свой исходный код с .NET Framework и другими библиотеками. Фреймворк предназначен для использования большинством новых приложений, созданных для платформы Windows. Microsoft также выпускает интегрированную среду разработки для программного обеспечения .NET под названием Visual Studio .
.NET Framework начинался как проприетарное программное обеспечение , хотя фирма работала над стандартизацией программного стека почти сразу, еще до его первого выпуска. Несмотря на усилия по стандартизации, разработчики, в основном из сообществ свободного и открытого программного обеспечения , выразили свое беспокойство по поводу выбранных условий и перспектив любой свободной и открытой реализации, особенно в отношении патентов на программное обеспечение . С тех пор Microsoft изменила разработку .NET, чтобы более точно следовать современной модели программного проекта, разработанного сообществом, включая выпуск обновления к своему патенту, обещая устранить опасения. [2]
В апреле 2019 года Microsoft выпустила .NET Framework 4.8, последнюю основную версию фреймворка в качестве фирменного предложения, за которой в августе 2022 года последовал .NET Framework 4.8.1. С тех пор выпускались только ежемесячные исправления ошибок безопасности и надежности для этой версии. Дальнейшие изменения этой версии не планируются. .NET Framework будет по-прежнему включаться в будущие выпуски Windows и продолжать получать обновления безопасности, без планов по его удалению с ноября 2023 года. [3]
Microsoft начала разрабатывать .NET Framework в конце 1990-х годов, первоначально под названием Next Generation Windows Services (NGWS), как часть стратегии .NET . К началу 2000 года были выпущены первые бета-версии .NET 1.0.
В августе 2000 года Microsoft и Intel работали над стандартизацией Common Language Infrastructure (CLI) и C# . К декабрю 2001 года оба были ратифицированы стандартами ECMA . [4] [5] Международная организация по стандартизации (ISO) последовала за ними в апреле 2003 года. Текущие версии стандартов ISO — ISO/IEC 23271:2012 и ISO/IEC 23270:2006. [6] [7]
В то время как Microsoft и их партнеры владеют патентами на CLI и C#, ECMA и ISO требуют, чтобы все патенты, необходимые для реализации, были доступны на « разумных и недискриминационных условиях ». Фирмы согласились соблюдать эти условия и сделать патенты доступными без уплаты роялти. Однако это не относилось к части .NET Framework, не охваченной стандартами ECMA-ISO, которая включала Windows Forms , ADO.NET и ASP.NET . Патенты, которыми владеет Microsoft в этих областях, могли сдерживать не-Microsoft реализации полной платформы. [8]
Windows Vista — первая клиентская версия Windows, в которую интегрирована .NET Framework.
3 октября 2007 года Microsoft объявила, что исходный код библиотек .NET Framework 3.5 станет доступен по лицензии Microsoft Reference Source License (Ms-RSL [a] ). [9] Репозиторий исходного кода стал доступен онлайн 16 января 2008 года и включал BCL, ASP.NET, ADO.NET, Windows Forms, WPF и XML. Скотт Гатри из Microsoft пообещал, что будут добавлены библиотеки LINQ, WCF и WF. [10]
Варианты .NET Framework Compact Framework и .NET Micro Framework обеспечивали поддержку других платформ Microsoft, таких как Windows Mobile , Windows CE и других встраиваемых устройств с ограниченными ресурсами. Silverlight обеспечивал поддержку веб-браузеров через подключаемые модули.
В ноябре 2014 года Microsoft также выпустила обновление своих патентных грантов, которое еще больше расширяет сферу действия за пределы предыдущих обещаний. Предыдущие проекты, такие как Mono, существовали в правовой серой зоне, поскольку предыдущие гранты Microsoft применялись только к технологии в «охваченных спецификациях», включая строго 4-е издания ECMA-334 и ECMA-335. Однако новое патентное обещание не устанавливает потолка для версии спецификации и даже распространяется на любые технологии среды выполнения .NET, задокументированные на MSDN, которые не были официально указаны группой ECMA, если проект решит их реализовать. Это позволяет Mono и другим проектам поддерживать паритет функций с современными функциями .NET, которые были введены после публикации 4-го издания, не подвергаясь риску патентного разбирательства по поводу реализации этих функций. Новый грант сохраняет ограничение, что любая реализация должна поддерживать минимальное соответствие обязательным частям спецификации CLI. [11]
31 марта 2016 года на конференции Microsoft Build компания Microsoft объявила , что полностью перелицензирует Mono по лицензии MIT даже в тех случаях, когда ранее требовалась коммерческая лицензия. [12] Компания Microsoft также дополнила свое предыдущее патентное обещание по Mono, заявив, что не будет заявлять о каких-либо «применимых патентах» против сторон, которые «используют, продают, предлагают для продажи, импортируют или распространяют Mono». [13] [14] Было объявлено, что проект Mono был передан в .NET Foundation. Эти разработки последовали за приобретением Xamarin , которое началось в феврале 2016 года и было завершено 18 марта 2016 года. [15]
В пресс-релизе Microsoft подчеркивается, что кроссплатформенное обязательство теперь позволяет использовать полностью открытый исходный код, современный серверный стек .NET. Microsoft выпустила исходный код для WPF, Windows Forms и WinUI 4 декабря 2018 года. [16]
Common Language Infrastructure (CLI) предоставляет нейтральную по отношению к языку платформу для разработки и выполнения приложений. Реализуя основные аспекты .NET Framework в рамках CLI, эти функции не будут привязаны к одному языку, а будут доступны на многих языках, поддерживаемых фреймворком.
.NET Framework включает в себя Common Language Runtime (CLR). Он служит в качестве исполняющего движка .NET Framework и предлагает множество служб, таких как управление памятью , безопасность типов , обработка исключений , сборка мусора , безопасность и управление потоками . Все программы, написанные для .NET Framework, выполняются CLR.
Программы, написанные для .NET Framework, компилируются в код Common Intermediate Language (CIL), а не напрямую компилируются в машинный код . Во время выполнения архитектурно-специфичный компилятор JIT преобразует код CIL в машинный код.
Скомпилированный код CIL хранится в сборках CLI . Как предписано спецификацией, сборки хранятся в формате файла Portable Executable (PE), общем для всех динамически подключаемых библиотек (DLL) и исполняемых EXE- файлов на платформе Windows. Каждая сборка состоит из одного или нескольких файлов, один из которых должен содержать манифест с метаданными для сборки. Полное имя сборки (не путать с именем файла на диске) содержит ее простое текстовое имя, номер версии, культуру и токен открытого ключа . Сборки считаются эквивалентными, если они имеют одинаковое полное имя.
Закрытый ключ также может использоваться создателем сборки для строгого именования . Токен открытого ключа определяет реальную личность подписавшего сборку. Только те, кто знает свой закрытый ключ (системы криптографии с двойным ключом), могут подписывать сборки, имеющие то же строгое имя, что и сборка предыдущей версии. Строгое именование требуется для добавления сборок в Global Assembly Cache .
Начиная с Visual Studio 2015, технология компиляции .NET Native позволяет компилировать код .NET приложений универсальной платформы Windows непосредственно в машинный код, а не в код CIL, но приложение должно быть написано либо на C#, либо на Visual Basic.NET. [17]
.NET Framework включает реализацию основополагающих стандартных библиотек CLI . Библиотека классов .NET Framework (FCL) организована в иерархии пространств имен . Большинство встроенных интерфейсов прикладного программирования (API) являются частью либо пространств имен System.*, либо Microsoft.*пространств имен. Эти библиотеки классов реализуют множество общих функций, таких как чтение и запись файлов, графическая визуализация, взаимодействие с базами данных и манипулирование XML-документами. Библиотеки классов доступны для всех языков, совместимых с CLI . FCL реализует библиотеку базовых классов CLI (BCL) и другие библиотеки классов — некоторые из них указаны CLI, а другие являются специфичными для Microsoft.
BCL включает в себя небольшое подмножество всей библиотеки классов и является основным набором классов, которые служат базовым API CLR. [18] Для .NET Framework большинство классов, считающихся частью BCL, находятся в mscorlib.dll, System.dllи System.Core.dll. Классы BCL доступны в .NET Framework, а также в альтернативных реализациях CLI, включая .NET Compact Framework , Microsoft Silverlight , .NET Core и Mono .
FCL относится ко всей библиотеке классов, которая поставляется с .NET Framework. Она включает BCL, расширенный набор библиотек, включая Windows Forms , ASP.NET и Windows Presentation Foundation (WPF), а также расширения базовых библиотек классов ADO.NET , Language Integrated Query (LINQ), Windows Communication Foundation (WCF) и Workflow Foundation (WF). FCL намного больше по объему, чем стандартные библиотеки для таких языков, как C++ , и сопоставима по объему со стандартными библиотеками Java .
С введением альтернативных реализаций CLI (например, Silverlight) Microsoft представила концепцию Portable Class Libraries (PCL), позволяющую потребляющей библиотеке работать на более чем одной реализации. С дальнейшим распространением реализаций подход PCL не смог масштабироваться (PCL — это определенные пересечения поверхности API между двумя или более реализациями). [19] В качестве следующего эволюционного шага PCL была создана библиотека .NET Standard Library, основанная на System.Runtime.dllAPI, найденных в UWP и Silverlight. Новые реализации CLI поощряются к реализации версии библиотеки Standard Library, позволяющей им запускать существующие сторонние библиотеки без необходимости создания их новых версий. Библиотека .NET Standard Library допускает независимую эволюцию слоев библиотеки и модели приложения в архитектуре .NET. [20]
NuGet — это менеджер пакетов для всех платформ .NET. Он используется для извлечения сторонних библиотек в проект .NET с помощью глобального библиотечного фида на NuGet.org. [21] Частные фиды могут поддерживаться отдельно, например, сервером сборки или каталогом файловой системы.
Microsoft представила C++/CLI в Visual Studio 2005, который является языком и средством компиляции программ Visual C++ для запуска в .NET Framework. Некоторые части программы C++ по-прежнему работают в неуправляемой среде выполнения Visual C++ , в то время как специально измененные части транслируются в код CIL и запускаются с помощью CLR .NET Framework .
Сборки, скомпилированные с использованием компилятора C++/CLI, называются сборками смешанного режима, поскольку они содержат собственный и управляемый код в одной и той же DLL. [22] Такие сборки сложнее поддаются обратному проектированию, поскольку декомпиляторы .NET , такие как .NET Reflector, раскрывают только управляемый код.
Поскольку компьютерные системы обычно требуют взаимодействия между новыми и старыми приложениями, .NET Framework предоставляет средства для доступа к функциям, реализованным в новых и старых программах, которые выполняются вне среды .NET. Доступ к компонентам Component Object Model (COM) предоставляется в System.Runtime.InteropServicesи System.EnterpriseServicesпространствах имен фреймворка. Доступ к другим функциям осуществляется через Platform Invocation Services (P/Invoke). Доступ к функциям .NET из собственных приложений осуществляется через обратную функцию P/Invoke.
.NET Framework представляет Common Type System (CTS), которая определяет все возможные типы данных и программные конструкции, поддерживаемые CLR, а также то, как они могут или не могут взаимодействовать в соответствии со спецификациями CLI. Благодаря этой функции .NET Framework поддерживает обмен типами и экземплярами объектов между библиотеками и приложениями, написанными с использованием любого соответствующего языка CLI .
CTS и CLR, используемые в .NET Framework, также обеспечивают безопасность типов . Это предотвращает некорректные приведения типов, неправильные вызовы методов и проблемы с размером памяти при доступе к объекту. Это также делает большинство языков CLI статически типизированными (с выводом типа или без него ). Однако, начиная с .NET Framework 4.0, Dynamic Language Runtime расширил CLR, позволив реализовать динамически типизированные языки поверх CLI.
Хотя Microsoft никогда не реализовывала полную структуру ни на одной системе, кроме Microsoft Windows, она спроектировала структуру как кроссплатформенную, [23] и реализации доступны для других операционных систем (см. Silverlight и § Альтернативные реализации). Microsoft представила спецификации для CLI (включая библиотеки базовых классов, CTS и CIL), [24] [25] [26] C# , [5] и C++/CLI [27] как в Ecma International (ECMA), так и в Международной организации по стандартизации (ISO), сделав их доступными в качестве официальных стандартов. Это позволяет третьим сторонам создавать совместимые реализации структуры и ее языков на других платформах.
Кроссплатформенный .NET Core (ранее .NET Core) официально доступен также для многих дистрибутивов Linux и MacOS. [28]
.NET Framework имеет собственный механизм безопасности с двумя общими функциями: Code Access Security (CAS) и проверка и верификация. CAS основан на доказательствах, связанных с определенной сборкой. Обычно доказательством является источник сборки (независимо от того, установлена ли она на локальном компьютере или была загружена из Интернета). CAS использует доказательства для определения разрешений, предоставленных коду. Когда вызывающий код требует предоставления ему определенного разрешения, CLR выполняет обход стека вызовов, проверяя каждую сборку каждого метода в стеке вызовов на наличие требуемого разрешения; если какой-либо сборке не предоставлено разрешение, она выдаст исключение безопасности.
Управляемый байт-код CIL легче поддается обратному проектированию, чем собственный код, если только он не запутан . [29] Программы- декомпиляторы .NET позволяют разработчикам, не имеющим навыков обратного проектирования, просматривать исходный код, стоящий за незапутанными сборками .NET. Напротив, приложения, скомпилированные в собственный машинный код, гораздо сложнее поддаются обратному проектированию, а исходный код почти никогда не создается успешно, в основном из-за оптимизаций компилятора и отсутствия рефлексии . [30] Это вызывает опасения в бизнес-сообществе по поводу возможной потери коммерческих секретов и обхода механизмов контроля лицензий. Чтобы смягчить это, Microsoft включила Dotfuscator Community Edition в Visual Studio .NET с 2002 года. [b] Сторонние инструменты обфускации также доступны от таких поставщиков, как VMware , Vi Labs, Turbo и Red Gate Software . Инструменты шифрования на уровне методов для кода .NET доступны от таких поставщиков, как SafeNet .
CLR освобождает разработчика от бремени управления памятью (выделения и освобождения по завершении); он сам управляет памятью, определяя, когда память может быть безопасно освобождена. Экземпляры типов .NET (объектов) выделяются из управляемой кучи; пула памяти, управляемого CLR. Пока существует ссылка на объект, которая может быть как прямой, так и через граф объектов , объект считается используемым. Когда ссылки на объект не существует и он не может быть получен или использован, он становится мусором, подлежащим сборке.
.NET Framework включает сборщик мусора (GC), который периодически запускается в отдельном потоке от потока приложения, который перечисляет все неиспользуемые объекты и освобождает выделенную им память. Это недетерминированный, уплотняющий сборщик мусора с функцией «марки и уборки» . GC запускается только тогда, когда был использован установленный объем памяти или в системе достаточно нехватки памяти. Поскольку не гарантируется, когда будут достигнуты условия для освобождения памяти, запуски GC являются недетерминированными . Каждое приложение .NET имеет набор корней, которые являются указателями на объекты в управляемой куче ( управляемые объекты ). К ним относятся ссылки на статические объекты, объекты, определенные как локальные переменные или параметры методов, которые в данный момент находятся в области действия, и объекты, на которые ссылаются регистры ЦП. [31] Когда запускается GC, он приостанавливает приложение, а затем для каждого объекта, на который ссылается корень, он рекурсивно перечисляет все объекты, достижимые из корневых объектов, и помечает их как достижимые. Он использует метаданные CLI и рефлексию для обнаружения объектов, инкапсулированных объектом, а затем рекурсивно обходит их. Затем он перечисляет все объекты в куче (которые изначально были выделены смежно) с помощью рефлексии. Все объекты, не помеченные как достижимые, являются мусором. [31] Это фаза маркировки . [32] Поскольку память, занимаемая мусором, не имеет значения, она считается свободным пространством. Однако это оставляет куски свободного пространства между объектами, которые изначально были смежными. Затем объекты сжимаются вместе , чтобы сделать свободное пространство в управляемой куче снова смежным. [31] [32] Любая ссылка на объект, аннулированная перемещением объекта, обновляется GC для отражения нового местоположения. [32] Приложение возобновляется после завершения сборки мусора. Последняя версия .NET Framework использует параллельную сборку мусора вместе с пользовательским кодом, делая паузы незаметными, поскольку это происходит в фоновом режиме. [33]
Сборщик мусора, используемый .NET Framework, также является поколенческим . [34] Объектам назначается поколение . Вновь созданные объекты помечаются как Поколение 0. Объекты, пережившие одну сборку мусора, помечаются как Поколение 1. Объекты поколения 1, пережившие другую сборку, называются Поколение 2. Фреймворк использует до объектов поколения 2. [34] Объекты более высокого поколения подвергаются сборке мусора реже, чем объекты более низкого поколения. Это повышает эффективность сборки мусора, поскольку более старые объекты, как правило, имеют более длительное время жизни, чем более новые объекты. [34] Игнорируя старые объекты в большинстве запусков сборки, в целом требуется меньше проверок и операций уплотнения. [34]
При первом запуске приложения .NET Framework компилирует код CIL в исполняемый код с помощью своего just-in-time компилятора и кэширует исполняемую программу в .NET Native Image Cache. [35] [36] Благодаря кэшированию приложение запускается быстрее при последующих запусках, хотя первый запуск обычно медленнее. Чтобы ускорить первый запуск, разработчики могут использовать утилиту Native Image Generator , чтобы вручную заранее скомпилировать и кэшировать любое .NET-приложение. [36]
Сборщик мусора, интегрированный в среду, может вносить непредвиденные задержки выполнения, над которыми разработчик имеет мало прямого контроля. «В больших приложениях количество объектов, с которыми должен работать сборщик мусора, может стать очень большим, что означает, что может потребоваться очень много времени, чтобы посетить и переупорядочить их все». [37]
.NET Framework предоставляет поддержку вызова потоковых расширений SIMD (SSE) через управляемый код с апреля 2014 года в Visual Studio 2013 Update 2. Однако Mono предоставила поддержку расширений SIMD с версии 2.2 в пространстве имен Mono.Simd в 2009 году. [38] Ведущий разработчик Mono Мигель де Икаса выразил надежду, что эта поддержка SIMD будет принята стандартом CLR ECMA. [39] Потоковые расширения SIMD были доступны в процессорах x86 с момента появления Pentium III . Некоторые другие архитектуры, такие как ARM и MIPS, также имеют расширения SIMD. В случае, если процессор не поддерживает эти расширения, инструкции моделируются программно. [40] [41]
.NET Framework была преобладающей реализацией CLI до выпуска .NET . Существуют и другие реализации частей фреймворка. Хотя механизм выполнения описан спецификацией ECMA-ISO, другие его реализации могут быть обременены патентными проблемами; стандарты ISO могут включать отказ от ответственности: «Обращаем внимание на возможность того, что некоторые элементы этого документа могут быть предметом патентных прав. ISO не несет ответственности за определение любых или всех таких патентных прав». [42] Сложнее разработать альтернативы FCL, который не описан открытым стандартом и может подлежать ограничениям авторских прав. Кроме того, части FCL имеют специфичные для Windows функции и поведение, поэтому реализация на платформах, отличных от Windows, может быть проблематичной.
Здесь перечислены некоторые альтернативные реализации частей фреймворка.
Фреймворки управляемого кода Microsoft и их компоненты лицензируются следующим образом:
есть несколько библиотек, которые включены в Mono и обычно используются такими приложениями, как Tomboy, но не требуются стандартом. И просто для ясности: мы не говорим о библиотеках, специфичных для Windows, таких как ASP.NET и Windows Forms. Вместо этого мы говорим о библиотеках в пространстве имен System, которые предоставляют общие функциональные возможности, ожидаемые программистами в современных языках программирования.
