Переваги та недоліки .NET: швидкий розвиток, велика поширеність і середні зарплати

.NET — це платформа від Microsoft для створення програмного забезпечення. Сьогодні вона досить популярна, про що свідчить велика кількість вакансій для .NET-розробників.

Згідно з рейтингом мов програмування, мовою С#, яку використовують для роботи з .NET, пишуть 14,3% розробників в Україні. Вона на третьому місці за популярністю використання, а 2021 року її частка навіть зросла.

Ми запитали в досвідчених .NET-розробників про те, які переваги, недоліки та перспективи вони бачать у платформі.

«.NET — довольно конкурентное решение для современной веб-разработки, особенно серверной части»

Влад Медведовський, R&D Team Lead в MWDN Ltd

Платформа .NET существует с 2002 года. Основная цель, которую преследовали ее создатели — это возможность создавать приложения различных типов (прежде всего web), которые могут выполняться на разных устройствах. Основа .NET — CLR, то есть Common Language Runtime, который позволяет абстрагироваться от конкретного языка программирования и выполнять код единообразно на всех платформах. С 2016 года CLR становится кроссплатформенной, и .NET начинает движение в направлении того, какой мы знаем платформу сейчас — удобное средство для разработки приложений различного рода, которые аналогично Java могут запускаться и на Windows, и на Unix-based системах.

Преимущества платформы

Речь пойдет о современной версии — .NET Core/.NET.

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

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

Отдельного внимания заслуживает ASP.NET MVC — фреймворк для веб-разработки на .NET. С одной стороны, из «коробки» он предоставляет большое количество уже готового функционала вроде авторизации, фильтров, роутинга, DI, model binding и еще много чего, а с другой стороны, он достаточно модульный для того, чтобы практически любую часть фреймворка можно было заменить на свою реализацию.

Отмечу еще простоту деплоймента решения в Azure или на IIS. При желании деплой можно сделать прямо из Visual Studio в два клика и таким образом не тратить время на развертывание в случае прототипов.

Недостатки платформы

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

Наличие большого количества технологий и подходов для разработки десктопных приложений. Сейчас параллельно существуют Windows Forms, WPF и MAUI. Без предварительного анализа сложно сказать, что из фреймворков могло бы лучше подойти под задачу. В вебе, например, начиная с .NET Core, Web API и MVC унифицировали в один фреймворк, и теперь для веба альтернатив по большому счету нет.

Периодическая смерть технологий в рамках платформы. Silverlight, XNA, project.json (новый формат файлов проекта для .NET Core), постоянные смены парадигм в SDK для MS Office аддонов, умирающий WCF, неопределенность с Blazor/MVC — это только часть примеров. В целом процесс естественный, но у неподготовленных людей может вызывать вопросы.

Я специально вынес отдельно C#, потому что он является как преимуществом, так и недостатком платформы. С точки зрения преимуществ мы имеем прекрасный компилятор, богатую стандартную библиотеку и неплохой синтаксис. Кроме того, это универсальный язык, на котором можно решать задачи из любых областей программирования.

Из недостатков, на мой взгляд, можно отметить уж слишком большое богатство синтаксиса, что повышает порог входа, особенно в последних версиях языка. Номинальная система типов периодически заставляет писать кода больше, чем необходимо (кстати, создатель C# таки сделал структурную систему типов в своем следующем после C# языке — TypeScript). Но это по большому счету придирки, потому что если нужно использовать больше функционального подхода, то всегда можно сделать сборку на F#, и благодаря CLI и CLR эти языки можно комбинировать в рамках одного проекта.

По итогу сегодня платформа .NET — довольно конкурентное решение для современной веб-разработки, особенно серверной части. Быстродействие среды выполнения, простота разработки, баланс между сложностью языка и его возможностями делают .NET хорошим выбором как для небольших проектов, так и для больших enterprise-решений.

«Платформа .NET совмещает в себе простоту написания приложений и готовый инструментарий»

Олексій Краєвий, Software Architect в Justin

Более чем за 20 лет существования платформа .NET собрала вокруг себя огромное количество разработчиков и уже давно занимает первые места в рейтингах по популярности, скорости разработки и выполнения программ, качеству и надежности среди конкурентов.


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

Я бы выделил такие ее преимущества:

  • Стандартные вещи: открытые исходники, мощные пакетные менеджеры NuGet или Paket, разнообразие языков, компилируемых под платформу с нативным интеропом между собой — C#, F#, IronPython.
  • Новые версии SDK и рантайма выпускаются регулярно и почти не содержат несовместимые изменения, обновление версии проходит всегда плюс-минус гладко.
  • Порог вхождения для новых разработчиков не очень высокий, и в 99% случаев можно найти готовую библиотеку под нужную задачу.
  • Платформа успешно находит золотую середину между безопасностью кода и быстродействием. Разработчики в большинстве случаев могут не беспокоиться о потреблении памяти или тонкостях взаимодействия с ресурсами ОС и ожидать, что платформа выполнит поставленную задачу оптимально.
  • Большая распространенность платформы и применение в разнообразных бизнес-сферах позволяет всегда выбрать проект на свой вкус.

Но в мире .NET не без недостатков:

  • Неповоротливость и многословность языка, который является де-факто стандартом в мире .NET/C#. С каждой новой версией его пытаются улучшить все большим количеством фич из мира функционального программирования. Но если их использовать на полную, то выражение одних и тех же конструкций, по сравнению с тем же F#, будет очень многословным и некрасивым.
  • Очень малое количество интеграций с продуктами для обработки потоков данных. JVM-мир в этом плане может предложить гораздо большую нативную интеграцию с продуктами Apache (NiFi, Flink, Spark etc).
  • Обратная сторона готовых стандартных библиотек и инструментов. Обычно .NET-разработчики не заморачиваются по поводу инструментов и библиотек во время разработки проектов. Если база данных — то SQL Server, если ORM — то Entity Framework, если облако — то Azure. Из-за обилия готовых и знакомых инструментов можно упустить другие подходы, которые решают поставленную задачу лучше.

В целом перспективы у платформы .NET очень хорошие. Я лично ожидаю продолжения работы в сфере быстродействия и более глубокой адаптации под разные архитектуры процессоров — ARM, M1. Самые популярные языки C# и F# будут получать плановые минорные изменения с сохранением обратной совместимости.

Я хотел бы, чтобы язык C# рано или поздно получил breaking change с переделкой синтаксиса и стал больше похож на Scala, чтобы из него убрали многословные конструкции. Это маловероятный сценарий, так как очень много приложений сейчас завязаны на этом языке, но поживем — увидим.

«Компенсации C#-разработчиков находятся на среднем уровне»

Максим Шнуренок, .NET Architect в LogiqApps AS


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

  • По данным Stack Overflow Developer Survey 2021, почти треть профессиональных разработчиков использует C# в той или иной степени. Это говорит о высокой доле уже существующих проектов, которые как минимум надо будет поддерживать (особенно учитывая большое количество инертных enterprise-решений).
  • По данным все того же опроса, .NET — лидер среди фреймворков по степени удовлетворенности использования, то есть людям очень нравится пользоваться платформой. Соответственно, решения на .NET будут продолжать развиваться в рамках той же платформы (к примеру, мигрировать с .NET Framework на .NET Core).
  • Ресурсы Microsoft.

Также позитивные факторы, которые, тем не менее, оказывают меньшее влияние:

  • C# — богатый язык, который продолжает активно развиваться.
  • Развитая экосистема — «из коробки» .NET предлагает огромное количество фич и интеграций, которые другие платформы добирают из OSS.

Есть и негативные моменты.

Компенсации C#-разработчиков находятся на среднем уровне.

Специфика использования — много еnterprise. Новые продукты/стартапы чаще делают на Python, Node.js и Go (на том же Djinni топовые компенсации заметно чаще встречаются именно для них). Это проблема и для меня в том числе.

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

При этом, если смотреть на платформу с точки зрения студентов или начинающих разработчиков, надо признать, что Python, Node.js, Go выглядят более конкурентными из-за текущей конъюнктуры. Объективно .NET заслуживает бОльшей популярности, но некоторые решения Microsoft были имплементированы слишком поздно: переезд в открытое программное обеспечение и движение в сторону модульности и унификации .NET Core.

.NET Core довели до ума только в версии 2.1 в 2018 году. И таким образом после async/await платформа в production-ready виде практически не получала прорывных обновлений целых пять лет, и это позволило остальным откусить кусок рынка. Будем надеяться, что в Microsoft не сбавят обороты, и .NET сможет и дальше достойно конкурировать с другими игроками.

«Под .NET можно писать на разных языках»

Володимир Вердиш, Senior Software Engineer .NET

Я разрабатываю бэкенды на .NET. Как по мне, более-менее объективно о плюсах и минусах можно говорить только в сравнении с чем-то. В данном случае хорошо бы обладать экспертизой также в другом языке и платформе, разрабатывать на них именно бэкенд. Мой опыт с чем-нибудь другим сильно уступает опыту с .NET. Поэтому написанное ниже прошу считать всего лишь личным мнением.


Плюсы:

  • Хоть пишу я бэкенды, но мне приятно, что на .NET можно писать настольные приложения, мобильные приложения, сайты, есть фреймворки для создания игр. Что-то даже с Machine Learning есть.
  • .NET-приложения можно запускать под разными операционными системами. Есть все необходимое, чтобы без особого напряга упаковать приложение в контейнер.
  • Современный .NET (и сама среда выполнения, и фреймворки типа ASP.NET Core) — это платформа с открытым исходным кодом.
  • Платформа развивается такими темпами, что вроде бы недавно переводили сервисы на .NET 5, а сейчас уже о .NET 6 надо думать. Наверное, эта тенденция когда-нибудь замедлится, но пока что можно сказать, что .NET именно развивается.
  • О платформе есть много информации: книги, видео. Как о самой .NET, так и об отдельных языках, поддерживаемых ею, среди которых наиболее популярный сейчас C#.
  • Под .NET можно писать на разных языках. Да, в каждом будут свои особенности и ограничения. Но даже на Python можно под .NET писать, если сильно хочется.
  • Под платформу написано много кода под что угодно.
  • Для .NET есть неплохие средства разработки.

Минусы:

  • Надо понимать, что такое .NET Core, .NET Standard, .NET Framework. Все созвучно и непонятно. Хорошая новость в том, что, начиная с .NET 5, теперь об этом всем думать не надо. Но плохая в том, что есть куча приложений, написанных до .NET 5, то есть какое-то время об этом думать придется.
  • Мне не хватает более продвинутых инструментов для исследования исходного кода сторонних библиотек. То, что есть сейчас, как по мне, работает не всегда хорошо. Хотелось бы иметь удобный способ исследовать код прямо со своего решения.
  • Переход со старых типов приложений на новые может быть непростым. Например, с ASP.NET WebForms на ASP.NET Core или даже с ASP.NET MVC на ASP.NET Core. Но с этим тоже, начиная с .NET 5, должно быть проще, если надо будет переводить его на какую-то версию выше.
  • Это управляемый код, то есть среда выполнения управляет памятью. Но на самом деле утечки памяти в .NET тоже случаются.
  • Управляемый код в теории медленнее, чем неуправляемый. Многие так говорят. На практике я никогда не видел, чтобы где-то что-то переписывалось с .NET на C++ по причине того, что не вывозит именно .NET. Разве что в очень высоконагруженных системах. Но я с таким не сталкивался. При этом я не думаю, что платформа уступает в производительности тем же Python, Node.js или Java. Основной фактор, влияющий на производительность, — это все-таки не язык программирования, а голова пишущего код программиста.

Перспективы. Я не вижу предпосылок к тому, чтобы .NET в следующие 10–20 лет куда-то делся или стал невостребованным.

«В .NET гарні перспективи для web-застосунків, серверних та cloud-продуктів, для highload та розподілених систем»

Іван Корнелюк, Software Developer в YouScan

Трохи контексту. В розробці я майже 20 років, з них понад 10 на .NET. Працюю в компанії YouScan, де маємо справу з величезними обсягами даних. Весь бекенд розробляємо на C# (крім Data Science, який традиційно на Python). Не використовуємо F# у розробці, тому все написане стосується С#.


Найбільшим недоліком .NET я вважаю монокультурність спільноти з величезним впливом Microsoft. Більшість розробників орієнтується на рішення та документацію від них. Альтернативні успішні проєкти зазвичай «маргіналізуються», щойно Microsoft випускає своє (часто opinionated) рішення. Тут можна згадати різні web-фреймворки, де де-факто стандартом зараз лишився ASP.NET від Microsoft, ORM-бібліотеки тощо. У світі Java чи Python значно більше різноманіття.

Дратує постійна потреба оновлюватись на нові версії фреймворків і бібліотек, часом не дуже сумісних. Стара стаття Fire and Motion від Joel Spolsky досі не втрачає актуальності. Компаніям доводиться докладати значних зусиль, щоб портувати код, лише щоб бути up to date, замість того, щоб розвивати свій продукт. Для прикладу, в .NET Core уже третій спосіб конфігурації сервісів. Часом здається, що у Microsoft є багато команд, які роблять схожі речі та яким треба виправдати своє існування.

Microsoft любить запускати нові продукти, щоб потім їх закрити. Якщо почекати кілька років, то труп нового продукту Microsoft може проплисти повз. Я щасливий, що жодного дня не проінвестував в Silverlight. Можливо, така доля спіткає і Blazor.

Це впливає на спільноту. Багато сильних розробників переходить на інший стек. Я не бачу значних інновацій, які з’являлися б не з боку Microsoft.

А що з перевагами?

З іншого боку, те, що за .NET стоїть така корпорація, як Microsoft, є і великим плюсом. Сама платформа зріла та швидко еволюціонує.

.NET — кросплатформна технологія. Це стосується як розробки, так і розгортання програм. В YouScan понад 100 сервісів на .NET 6, які розгортаються на сотнях машин в Kubernetes на Linux. Майже всі розробники працюють на MacOs чи Linux, використовуючи JetBrains Rider.

C# — прекрасна мова програмування, в якій швидко з’являються класні та новітні штуки. Наприклад, async, який поширився на інші мови програмування, вперше з’явився саме в F# та згодом в C#. Чудово підходить для вирішення різноманітних завдань — від моделювання предметної галузі до написання високонавантажених систем.

Імпонує потужний інструментарій розробки в .NET.

Я вдячний .NET та великій Kyiv Alt .NET спільноті, де свого часу знайшов багато крутих друзів!

Перспективи платформи

Вважаю, що в .NET гарні перспективи для web-застосунків, серверних і cloud-продуктів, для highload та розподілених систем. Є зрозумілий план щорічних релізів платформи та версії С#.

Проте .NET традиційно не вважають привабливою платформою у світі стартапів і продуктових компаній. Їх відносно мало як в Україні, так і за кордоном.

Чи варто початківцю вивчати .NET для першої роботи? Чому б і ні, якщо є зацікавленість у серверних, розподілених чи highload системах. Тоді це прекрасний вибір.

Якщо більше цікавить фронтенд або мобільні застосунки, то, думаю, варто звернути увагу на інші платформи. Насамперед на TypeScript і нативну мобільну розробку.


У попередньому випуску розробники розповідали про переваги та недоліки мови Python.

Пишіть у коментарях, про яку мову хочете прочитати далі.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному1
LinkedIn



33 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Лично меня бесят в .NET:

1. отказ MS от своих же технологий без предоставления migration path (примеры: SyncFx, WCF, Silverlight, OData)
2. раскол на .NET Framework и .NET Core: сначала идея была «начнём с нуля и сделаем лучше», потом было долгое пыхтение на месте, а закончили переименованием и ясным сигналом «переходите на новое которое хорошо забытое старое, но лучше, а не то...»
3. фиаско EF: от 6 тяжких мажорных версий до полного переписывания в EF Core (и снова с нетривиальной миграцией). показали EF Core 6 в ноябре с теми же возможностями, что мы имели 10 лет назад. держат нас за дураков.

Но конечно, есть и много хороших моментов. Именно на .NET я зашипил несколько крупных приложений, которые уже годами работают у заказчиков. В C# добавляют все больше фич, которые позволяют использовать подходы из обычного C. Красота, производительность и безопасность!

Управляемый код в теории медленнее, чем неуправляемый. Многие так говорят.

а ось у CLR via C# автор стверджував, що завдяки оптимізації під проц у рантаймі, часто перформанс вищий

Я полагаю, что это утверждение истинно в контексте сравнения говнокода на .NET с говнокодом на С++. Под говнокодом прошу понимать код, который пишется 98% программистов, к коим, скорее всего отношусь и я.

Что означает «в теории»? В теории, в данном случае, означает, что если написать простенькую программу или какой-то метод, то в C++ или каком-то компилируемом языке он с большой вероятностью отработает шустрее. Просто даже потому, что в C++ приложении будет тратиться куда меньше ресурсов на управление памятью. Разница эта может составлять какие-то мили, микро или наносекунды. Но, скорее всего она будет, при условии, что код на .NET и С++ написан максимально хорошо, как можно написать на данном языке.

Если не убедил, можете вот ещё глянуть, например: benchmarksgame-team.pages.debian.net/...​stest/csharpcore-gpp.html. Я не знаю, насколько это авторитетный источник, это просто первое, что я открыл в Гугле.

Но это все, как я сказал, теория. На практике же есть нюансы (98% программистов, о которых я выше упоминал).

Уж лучше-бы не менялось — этот новомодный сахар

public (int a, double b, double c, double d, DateTime dt) ReturnData()

и

settings?.Container?.Runner?.IsReady == true

Превращщают код в какую-то хренову лапшу

settings?.Container?.Runner?.IsReady == true

Т.е. удобнее 3 проверки на null?..

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

bufferLabel.Text =     $"Buffer : {bufferingStatus.BufferedSeconds}s, {container?.VideoPlayer?.CurrentItem?.PlaybackLikelyToKeepUp}"; var videoTrack = container?.VideoPlayer?.CurrentItem?.Tracks[0]; var videoDesc = videoTrack?.AssetTrack?.FormatDescriptions[0]; videoLabel.Text =     $"{videoDesc?.MediaType}/{videoDesc?.VideoCodecType} {videoTrack?.AssetTrack?.TrackID} {videoTrack?.AssetTrack?.NaturalSize.Width}x{videoTrack?.AssetTrack?.NaturalSize.Height} {container?.LastIndicatedBitRate})"; var audioTrack = container?.VideoPlayer?.CurrentItem?.Tracks[1]; var audioDesc = audioTrack?.AssetTrack?.FormatDescriptions[0]; vAudioLabel.Text =     $"{audioDesc?.MediaType}/{audioDesc?.AudioFormatType} {audioTrack?.AssetTrack?.TrackID} {audioDesc?.AudioStreamBasicDescription.Value.SampleRate} {audioDesc?.AudioStreamBasicDescription.Value.ChannelsPerFrame} {audioDesc?.AudioStreamBasicDescription.Value.FramesPerPacket})";

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

Превосходно! Я в восторге!

Стоп) Кто-то в компании прособеседовал человека, который это писал, правильно? И, извините, это всего лишь несчастный код, т.е. middle-уровень компетенции специалиста. Если человек обучаемый, максимум через неделю привыкнет к nullable, а если нет — может, дело всё-таки не в nullable?..

То, что вы привели в пример — это следствие, а не причина. Напишите этот код лучше без nullable операторов. Именно тот код, который вы привели.

перефразуючи анекдот: чого тільки програмісти не придумають щоб перевірку на null не робити )))

Уж лучше-бы не менялось — этот новомодный сахар
public (int a, double b, double c, double d, DateTime dt) ReturnData()
и
settings?.Container?.Runner?.IsReady == true
Превращщают код в какую-то хренову лапшу

кортежи до .Net Core существовали, а оператор ? позволяет избавиться от написания проверок на null.

Мне платят за легаси, иногда бывает модернизирую, если это выгодно. Да и я пришёл к мысли, что легаси это любой код, который в продакшене работает. :-) Физерс, по-моему, про это писал.

Работаю с .net еще со времен его первой версии.
В принципе хорошая платформа, но где-то после 2014 года подумывал, что нужно бы переходить с .net на что-то более современное и кроссплатформенное в веб-разработки. Но тут как раз появился .net core и стал активно исправлять все, что мне не нравилось в c#/.net
На сегодняшний день сплошное удовольствие разрабатывать на c#/.net core.
Единственное что не нравится — то что до сих пор экосистема очень обособленная.
Компании деляться на дви типа:
— тех у кого вообще нет .net
— тех у кого есть .net — и тогда у них всё-всё на .net (за минимальным исключением некоторых инструментов типа ML).
Еще не нравится когда у компаний много легаси на старом .net, который приходится поддерживать.
Хотелось бы и большей гибкости в выборе компаний и большего разнообразия технологий, с которыми приходится работать.

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

а чего именно не хватает? что бы хотелось ещё вдобавок к тому, что уже предоставляет dotPeek?

Судя по постановке, автор использует голую VS или VS Code, потому что Rider из коробки умеет не только декомпилировать, но еще и дебажить сторонные библиотеки «прямо со своего решения».

Что неудобно:
— dotPeek — это отдельное приложение. Если пишешь код и хочется посмотреть что-то внутри другой библиотеки — надо переключаться и выполнять дополнительные телодвижения.
— Resharper решает проблему описанную выше. С ним мы имеем dotPeek внутри VS. Но он создает другие проблемы, которые проявляются в виде постоянно «задумчивой» IDE. Вдобавок он платный.
— я не могу сказать, что dotPeek или любой другой подобный инструмент позволяет на 100% качественно просматривать и исследовать исходный код, как если бы вы это делали с оригинальным исходным кодом.

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

Что интересного умеет Решарпер в сравнении со Студией 2022? У меня на компе стоит 2019 Студия с Решарпером и 2022 Студия без. Если не говорить, про просмотр исходного кода, я разницы не вижу с Решарпером и без.

22 студия просто восхитительная, спору нет, пользуюсь неделю и уже доволен :)
проблема состоит в том, что в кровавом энтерпрайзе сплошь и рядом переход на следующую студию происходит с задержкой в 2-4 года. знаю проекты в одном из лидеров аутсорса, где разработка идёт в 15 версии и перемены даже не запланированы. и тут решарпер решает.

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

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

Реліз .NET 1.0 був у 2001 році, а не у 2002 (тоді вийшла 1.1, яка і була основною версією доволі довго)

Дякую за зауваження, але ми посилаємось на офіційну документацію, в якій роком релізу вказаний 2002-ий

оу, точно. У вікіпедії помилка про 2001 :)

Как раз в 2002. Поэтому именно в этом году и отмечается двадцатилетие платформы: dotnet.city/dot-net-loves-me

Підписатись на коментарі