Платформа .NET появилась в начале 2000-х годов. Она объединяла «под одной крышей» несколько языков программирования, что было в новинку для того времени. Но разработчики платформы утверждали, что это новшество несет несомненную пользу: программисты начали создавать свои приложения на тех языках, которые знали лучше всего, которые лучше подходили для решения своих задач.
Еще одним новшеством платформы .NET была технология активных серверных страниц ASP.NET (Active Server Page). С её помощью можно было относительно быстро разработать веб-приложения, взаимодействующие с базами данных. Важной особенностью ASP.NET считалась возможность использования всей мощи объектно-ориентированного программирования для веб-разработки. Приложения, написанные с использованием этой технологии, обладают лучшей производительностью и защитой. По крайней мере, в это верили инженеры Microsoft.
Сложно переоценить роль такого нововведения, как веб-сервисы. .NET предоставлял разработчикам инструментарий для их использования. Программисты получили возможность реализовывать взаимодействие с веб-сервисами на любом языке платформы .NET.
Однако слишком тесная интеграция ASP.NET с Windows IIS сделала невозможным использование альтернативного веб-сервера для хостинга приложений. Эти обстоятельства с течением времени вызывали все больше критики со стороны сообщества разработчиков и являлись неблагоприятным фактором для развития ASP.NET MVC.
Визуальное проектирование интерфейса – Web Forms, Windows Forms, затем WPF – также является существенным достижением разработчиков. Сейчас это может кому-то показаться смешным, но тогда качественный инструмент для создания GUI был в новинку.
Кроме классической реализации платформы появились также .NET Compact Framework (версия .NET Framework, предназначенная для запуска приложений на устройствах, основанных на платформе Windows CE.) и .NET Micro Framework (реализация платформы Microsoft .NET для встраиваемого применения в 32- и 64-разрядных микроконтроллерах).
Со временем платформа .NET менялась. Если изначально она выпускалась как инструментарий для пользователей операционной системы Windows, то в дальнейшем разработчики пошли навстречу поклонникам других ОС. Так, например, в сообществе open source появился проект Mono, который был официально признан реализацией .NET на Unix-подобных операционных системах.
А летом этого года Microsoft выпустила кроссплатформенный аналог .NET под названием .NET Core.
Тем не менее, многие критические замечания остаются актуальны, несмотря на то, что Microsoft уже много лет пытается ликвидировать последствия не совсем удачной реализации и архитектуры платформы .NET.
Главная претензия критиков – это нерациональное использование памяти системы. Якобы конкурирующие платформы используют память куда экономнее, и более того, многие из них являются бесплатными.
Конечно же, к настоящему времени платформа существенно изменилась и, скажем так, размножилась. Однако такое многообразие заставляет задаваться вопросами о том, какие перспективы у того или иного направления развития .NET, насколько эта платформа сегодня актуальна, как меняются требования к .NET-программистам и так далее.
О том, куда и зачем идет платформа, мы поговорили с экспертами отрасли.
Аркадий Кочетков, Софтнео, ведущий инженер-разработчик:
Прошла ли .NET свой пик? На каком этапе развития находится технология?
Не прошло, продукты MS никуда не делись из энтерпрайза. Но сейчас это определенно не модно.
Насколько актуальна .NET в условиях засилья мобильных технологий, больших данных, интернета вещей?
В условиях мобильных технологий и интернета вещей (Java популярнее, чем Xamarin, а Mono и всякие Netduino сильно на любителя, например) я бы смотрел в сторону других решений. Но если без .NET вам и жизнь не мила, то почему бы и нет?
В каких направлениях разработки у .NET больше шансов?
Web.
Если бы Microsoft не продвигал свое детище, какова могла быть судьба .NET?
Судьба была бы печальной. Кто-то подхватит разработку открытых сорсов, существующие решения будут поддерживаться, но создавать новые на основе технологии, потерявшей поддержку, побоятся. Проектов будет становиться все меньше, а со временем и не останется.
Или под «продвижением» понимался PR? Только ленивый не слышал про .NET.
Каковы преимущества .NET перед конкурирующими технологиями?
Синтаксический сахар c#, бОльшая продуманность (в сравнении с основным конкурентом), классные инструменты, простота в использовании с другими продуктами MS.
С какими перспективными технологиями посоветуете комбинировать .NET начинающим разработчикам?
Если вы начинающий разработчик, то начните с самого языка, алгоритмов и структур, а если вы по какой-то причине обратили свой взор на .NET, уже умея что-то, то и сами все прекрасно знаете. Но если как-то пропустили, то посмотрите на .NET Core.
Никита kekekeks Цуканов, Гуру велосипедостроения:
Прошла ли .NET свой пик? На каком этапе развития находится технология?
Не вижу кривой с одним экстремумом в развитии .NET. Зрелости технология в моём видении достигла ещё в дремучем 2005-ом году в момент выхода .NET 2.0, с тех пор непрерывно идёт динамичное развитие эволюционного характера, сочетающее в себе как качественные, так и количественные изменения. Помимо создания своего языки и инструментарий постоянно перенимают что-то из других языков и сред. Я не вижу никаких предпосылок к закату в ближайшем будущем.
Насколько актуальна .NET в условиях засилья мобильных технологий, больших данных, интернета вещей?
Одним из важных преимуществ .NET является тот факт, что писать можно что угодно и подо что угодно. Хотите мобильное приложение — берите Xamarin. Хотите что-то считать на сервере? Пожалуйста!
.NET долгое время затачивался под серверное использование. Интернет вещей? Смотря что понимать под устройством из IoT. Если это нечто с 64Кб оперативной памяти то, конечно, лучше всё же воспользоваться С (хотя при наличии желания и фанатизма можно взять .NET Micro). Если у вас есть возможность туда впихнуть хоть какую-то ОС, то вы можете продолжать писать на C#. С приходом CoreRT, который обеспечит возможность сборки в нативный код под любую платформу (в том числе средствами LLVM или трансляции в ANSI C) это станет ещё проще и удобнее.
В каких направлениях разработки у .NET больше шансов?
Традиционно C# и .NET использовались для серверных приложений и десктопных приложений с UI. И в этих традиционных для себя областях они чувствуют себя лучше всего. Сейчас с появлением Xamarin для мобильных устройств стал доступен стек для разработки UI с использованием нормальной системы биндингов, шаблонизированных контролов и XAML, так что предыдущее высказывание можно распространить и на мобильные устройства. Если меня спросить практически про любой проект, на чём его нам лучше делать, то я c высокой вероятностью отвечу, что на .NET.
Есть, правда, в покрытии технологии один большой пробел: кроссплатформенный UI, который пока толком не закрыт, хотя и есть решения.
Если бы Microsoft не продвигал свое детище, какова могла быть судьба .NET?
Вы можете сделать сколь угодно замечательный продукт, но если о нём никто не знает, то им никто не будет пользоваться.
Каковы преимущества .NET перед конкурирующими технологиями?
По сути мы сейчас получаем по переносимости аналог С, но со всеми преимуществами среды с управляемым кодом.
Как мне кажется, наибольший эффект можно получить от синергии, когда у вас на сервере, десктопе и всех мобильных устройствах используется один язык, одна технология. В таком сценарии переключаться между участками кодовой базы может практически любой разработчик из команды, вы так же можете разделять один и тот же код между элементами системы, если потребуется.
Также можно начать очередную дискуссию на тему преимуществ компилируемых языков со строгой статической типизацией, но тут очень много людей с разными мнениями.
Как вы оцениваете уровень разработчиков: появилось больше низкоквалифицированных .NET-программистов или их число уменьшилось, а уровень вырос? Или распределение выглядит по-другому?
Я не заметил роста числа низкоквалифицированной рабочей силы «работающей за еду», как это в своё время произошло с PHP, но и сильного кадрового голода тоже не наблюдаю.
С какими перспективными технологиями посоветуете комбинировать .NET начинающим разработчикам?
Это зависит о того, что вы хотите делать, изучите окружающий планируемую сферу деятельности стек технологий. Если хочется писать логику на сервере, разберитесь, как работает SQL (желательно посмотреть на несколько диалектов и понять, что всё равно будете использовать ORM), как работают nosql решения (mongodb, redis, да и на вещи типа elasticsearch посмотреть не мешает), на системы передачи сообщений (RabbitMQ, MSMQ, ActiveMQ, посмотрите на библиотеки типа MassTransit, EasyNetQ).
Если хочется быть чуть ближе к веб-фронтэнду, то нужно знать стандартный набор HTML/JS/CSS и как минимум научиться пользоваться инструментарием node.js, тем более, что он сейчас интегрирован в toolchain сборки нового ASP.NET.
Если вы хотите писать устанавливаемые приложения, работающие с пользователем, то для начала стоит освоить десктопный WPF и сопутствующие ему библиотеки (пощупать MVVM-фреймворки типа Caliburn.Micro, Prism, MvvmCross, разобраться с внутренностями XAML), а затем уже открывать для себя разработку под мобильные устройства, где придётся ещё и изучать их.
Максим Аршинов, CEO, HighTech:
Прошла ли .NET свой пик? На каком этапе развития находится технология?
Я думаю, что не прошла. .NET сейчас активно развивается сразу в нескольких направлениях. Хотите производительный сервер с горизонтальным масштабированием: берите .NET Core. Хотите кроссплатформенную мобильную разработку — Xamarin. Желаете писать C#-код на Mac — Rider IDE. Хотите Machine Learning и Data Science — F# вам в руки.
Конечно, многое из вышеперечисленного — абсолютный bleeding edge. Нужно понимать, что многие инструменты, к которым мы привыкли, все еще недоступны. Многих разработчиков привели в шок события ASP.NET Core RC1 — RC2. Но не будем забывать, что происходит в экосистеме JavaScript. По сравнению с этим в мире .NET все спокойно.
Можно сказать, что у .NET сейчас «период перестройки». С одной стороны, мы накопили значительный объем кода корпоративных приложений, который никто никогда не перепишет, а значит, мы будем поддерживать его еще десятки лет. С другой – Microsoft очень быстро трансформируется и трансформирует .NET под нужды бизнеса. Современный .NET делает ставку на Azure, Linux и мобильные платформы.
Как будут уживается кровавый энтерпрайз с «модными веяниями», покажет время.
Насколько актуальна .NET в условиях засилья мобильных технологий, больших данных, интернета вещей?
Нет никакого засилья больших данных, мобильных технологий и прочей ерунды. Это все marketing bullshit. Да, в США есть несколько известных всем компаний, которые занимаются подобными вещами. Но это совершенно иные задачи и бюджеты.
Почему-то многие считают, что если подключить к своей БД hadoop / spark / «впишите свое», то вдруг внезапно все станет замечательно и прибыли вырастут в квадриллион раз.
Современные СУБД успешно справляются с хранением данных в 90% случаев. Чаще всего, проблемы в плохом проектировании и неправильном использовании инструментов. Для мобильных технологий все-равно нужен server-side и его нужно написать. Почему бы не сделать это на .NET и не захостить в Azure, тем более, что Microsoft активно занимается поддержкой Docker?
В каких направлениях разработки у .NET больше шансов?
Я думаю, что на стороне сервера. Swift уже достаточно вменяемый язык, на Android есть Java. Windows Phone по прежнему не нашел свою нишу. Должно что-то очень серьезное произойти, чтобы руководители уровня CTO/CEO всерьез рассматривали Xamarin.
Если бы Microsoft не продвигал свое детище, какова могла быть судьба .NET?
.NET бы не было, потому что никто бы не выделил денег на его разработку. Писали бы на Java.
Каковы преимущества .NET перед конкурирующими технологиями?
Мультипарадигмальность, сильная типизация, быстрое развитие языка C#, поддержка Microsoft.
Как вы оцениваете уровень разработчиков: появилось больше низкоквалифицированных .NET-программистов или их число уменьшилось, а уровень вырос? Или распределение выглядит по-другому?
Сложно сказать. С появлением LINQ сильно упростились задачи манипуляций с данными, поэтому, в целом, с типовыми задачами разработчики справляются сравнительно неплохо.
Проблемы начинаются, когда нужно сделать шаг влево или вправо. Я заметил, что многие .NET-разработчики не понимают как работает TPL, LINQ или async/await. Бывает, что даже говорят, дескать «var приводит к не строгой типизации».
В итоге есть пропасть между «джуниорами» и «сеньорами». Либо человек умеет набивать строчки кода по примеру, не понимая, как это работает, либо может разбираться в платформе лучше тебя. Я ощущаю острую нехватку тим-лидов на рынке.
С какими перспективными технологиями посоветуете комбинировать .NET начинающим разработчикам?
ES6 + React или Type Script / Angular, NodeJS; Java / Scala. Очень рекомендую изучить Erlang или Haskell.
В одном из интервью ИТ-специалист и автор книг по .NET Джеффри Рихтер размышлял о том, как бы он спроектировал и реализовал платформу, если бы была возможность создать все «с нуля»:
Безусловно, в .NET и C# сегодня есть вещи, которые и Microsoft и лично я хотели бы реализовать иначе. Стоило бы сделать .NET более «чистым», минималистичным, чтобы он не использовал так много памяти, как это происходит сейчас, не был столь «тяжелым».
Если сегодня всё это можно было бы написать «с нуля», я думаю, стоило бы выделить небольшое ядро всей платформы — систему CLR-типов и сборщик мусора. Это должна быть основа, а вот всё остальное уже могло бы подключаться к платформе чем-то вроде «плагинов».
Таким образом, одно и то же ядро работало бы во всех версиях платформы, что дало бы большую гибкость. А уже команды разработчиков конкретной платформы могли бы добавлять остальной функционал, по модели «plug-and-play».
Но .NET никогда не проектировался таким образом. Он изначально создавался, как цельная, монолитная платформа.
Комментарии (114)
DizelGenerator
20.10.2016 22:40-4С возросшими объемами памяти в устройствах (ноутбуках, серверах) разработчикам .NET нынче не приходится заморачиваться особенностями ее использования, оттого и низкая их квалификация, и качество кода становится поистине ужасным. «Кодируй, как получится, все равно будет работать». Это и плюс (скорость разработки, ниже порог вхождения), и минус (непродуманно написанное приложение рано или поздно все равно сожрет всю память объектами GC2).
Anarions
20.10.2016 22:57+28Как будто на языках с GC пишут исключительно говнокод, а на языках с ручным управлением памятью — исключительно шедевры.
Anarions
20.10.2016 23:26И это замечание, естественно, повод сливать мне карму. Надеюсь все поучавствовавшие чувствуют себя лучше, потому-что в остальном у них явно какие-то проблемы.
ennui
20.10.2016 23:40-12Это не замечаение, это вброс на три с минусом.
Anarions
20.10.2016 23:52+16Вброс на три с минусом — говорить о том что из-за GC «качество кода становится поистине ужасным»
ennui
20.10.2016 23:55+4Качество кода становится поистене ужасным, когда его пишет поистине ужасный кодер вне зависимости от языка и платформы.
Anarions
21.10.2016 00:05+9И именно это я и сказал двумя комментариями выше.
ennui
21.10.2016 01:54-8Так как управлением памяти не надо замарачиваться- .net программисты = фиговые програмисты, а все остальные дартаньяны. Вот что вы сказали
senya_z
21.10.2016 02:10+3Вы точно не путаете обсуждаемый коментарий с коментарием, на который он был ответом? Потому что лично для меня
«Как будто на языках с GC пишут исключительно говнокод, а на языках с ручным управлением памятью — исключительно шедевры.»
и
«Качество кода становится поистене ужасным, когда его пишет поистине ужасный кодер вне зависимости от языка и платформы.»
несут примерно одинаковую смысловую нагрузку, хоть и с разной эмоциональной окраской.
mezastel
21.10.2016 00:00+28Я не понимаю с чего тут взяли что .NET «немоден» вдруг. Язык C# прекрасен, лучшего мейнстрим языка пока нет. .NET вон становится переносным, хоть и без UI. Вообще все супер!
Serginio1
21.10.2016 10:37Есть Avalonia Пока правда pre, но развивается
mezastel
21.10.2016 10:39Ну, с UI реальная проблема — по идее, нужен портативный WPF, но Microsoft завязали его на аппаратное ускорение, что не очень переносимо.
Serginio1
21.10.2016 11:05На DitectX. Вин фоны тоже поддерживают DitectX. Но вот XAML есть и на Xamarin http://metanit.com/sharp/xamarin/2.4.php
Надо подождать NetStandard 2 и следующей версии .Net Core
kekekeks
21.10.2016 12:29Скажите, а зачем вам нужен NetStandard2? Чего именно не хватает в 1.1?
Serginio1
21.10.2016 12:38Ну 1.1 еще нет. А вот в 1.01 очень многого нет. Смотрим дорожную карту
kekekeks
21.10.2016 13:16Кого нет? Профили сборки .NETStandard вплоть до 1.6 доступны (карта поддержки оных фреймворками есить по же ссылке из предыдущего комментария), мы уже пользуемся. По последней ссылке дорожная карта .NET Core.
Не надо путать наборы API (NETStandard, PCL) и целевые платформы (.NETFX, Mono, .NET Core)Serginio1
21.10.2016 13:57Так в .Net Core не хватает кучи классов. Нет WCF, SignalR и еще кучи классов. Библиотек под NETStandard раз два и обчелся. И в Итоге то .Net Core 1.2 и будет совместим с NetStandard 2
Planned 1.2 features
•.NET Standard 2.0 support, bringing .NET Core to parity with .NET Framework and Mono for a large collection of base types.
Notes:
•The 1.0 release is accompanied with a preview version of the Visual Studio and command-line tooling. The Visual Studio tooling for 1.0 through 1.2 based on MSBuild and csproj should be publicly available in Fall 2016 and reach RTM quality in Spring 2017.kekekeks
21.10.2016 14:08А как .NET Core 1.2 связано с UI и аппаратным ускорением графики и зачем для этого ждать NETStandard2.0? .NET Core в текущем своём виде мало полезен, пока на этот самый NETStandard не перенесут все библиотеки.
От профиля сборки NETStandard же польза вполне определённая вот уже сейчас: единый бинарник для NETFX, десктопного Mono, WinPhone и Xamarin-овских мобильных платформ. Мы сами на него хотим переносить авалонию, но нам для этого за глаза должно хватить 1.1, там всё нужное есть.
Serginio1
21.10.2016 14:18Ну например я хотел поработать с XML Schema, SignalR, WCF, а их пока нет. Авалония пока в альфе. Хотел к Xamarin прикрутить NetStandard пока не получилось. Там как раз и проблема с кучей профилей. А когда 1.1 то вышел. Вот NET Core 1.0.2 И то там инсталятор для IOS подправлен
1.1 там только исправления. То, что можно использовать и 1.0 не спорю, но с 1.2 это делать будет значительно прощеkekekeks
21.10.2016 14:19Вы сейчас путаете версии .NET Core и .NETStandard. Это разные вещи.
Serginio1
21.10.2016 14:30.NET Core это Фреймворк.
Но в .NET Core 1.2 есть поддержка NETStandard2
А в NetStandard 2 поддержка большего количества классов
Я то как раз и использую библиотеки под NetStandard https://habrahabr.ru/users/serginio1/topics/
Опять же, что касается профилей PCL https://docs.microsoft.com/en-us/dotnet/articles/standard/library
Мы говорим NetStandard 2, подразумеваем .Net Core 1.2kekekeks
21.10.2016 14:32Мы говорим NetStandard 2, подразумеваем .Net Core 1.2
Вот не надо одно с другим перемешивать, это вызывает ненужную путаницу.
Serginio1
21.10.2016 14:35Так .Net Core 1.2 бессмысленен без NetStandard 2. А NetStandard 2 это стандартная библиотека для всех .Net Фреймворков. Поэтому основой то как раз и является NetStandard 2.
Прошу прощения, если неправильно выразился.kekekeks
21.10.2016 14:39NetStandard — это набор API, который должен поддерживаться фреймворком, чтобы использовать в нём библиотеку, которая собрана под этот самый NetStandard. По сути это аналог профилей PCL, поменялся лишь подход к составлению перечня API.
Serginio1
21.10.2016 14:47Угу вместо кучи профилей, при смене которых все ломается будет 1 профиль.
Да и с выходом NetStandard 2 появится больше библиотек под него, так как он будет уже совместим со всеми Фреймворками. Сейчас выгоднее делать под PCL, а вот они не все совместимы с .Net Corekekekeks
21.10.2016 14:51Да и с выходом NetStandard 2 появится больше библиотек под него, так как он будет уже совместим со всеми Фреймворками.
Вообще-то нет. Чем ниже версия .NETStandard, тем больше фреймворков с ним совместимо. Чтобы быть совместимым с .NET 4.5 нужно использовать .NETStandard1.1, например, более поздние версии .NETStandard с .NET 4.5 не совместимы.
Serginio1
21.10.2016 14:57Здесь главное не совместимость, а возможности. Кстати в NetStandard 2 они откатились до 4.6.1. Сейчас то под NetStandard очень мало библиотек
VioletGiraffe
21.10.2016 13:35+1А кому он нужен без UI, осмелюсь спросить? Кроме серверного back-end, конечно. Какой же это мейнстрим, если клиентские приложения можно писать только под Windows?
kekekeks
21.10.2016 14:18+1Ну во-первых, есть универсальная обёртка с поддержкой XAML над нативными для платформ фреймворками (набор контролов достаточно богатый, сейчас вот заснял как оно с GTK-бакэндом на убунте выглядит). А что касается аналога WPF с полностью своим рендерингом, то мы работаем над этим.
VioletGiraffe
21.10.2016 14:35Спасибо, это очень интересно. WPF или нет — это уже не так важно, ИМХО. Я даже люблю, когда на разных платформах одно и то же приложение выглядит нативно.
Serginio1
21.10.2016 21:37+1Я не думаю, что для MS интересно делать WPF кроссплатформенным учитывая процент декстопов на котором стоит Windows.
А вот для мобильных устройств будут развивать Xamarin Forms.
А вот для серверов WPF не нужен, а интересны им юниксы линуксы именно из-за облаков.
yarric
21.10.2016 18:03Язык C# прекрасен, лучшего мейнстрим языка пока нет.
Что думаете о Swift?
mezastel
21.10.2016 18:05Очень нравится. Серьезно, продуманный язык, вот так сходу придраться не к чему, но с другой стороны я на нем не пишу. У Swift и C# одна проблема — кроссплатформенный UI. Ну, у Swift еще проблема что Windows этому языку амбивалентен, но у нас сейчас и порты есть, и Ubuntu под Linux стоит, так что проблемы вроде особой нет.
robert_ayrapetyan
21.10.2016 00:33+1Есть некий кровавый ынтырпрайз проект 16-летней давности на classic ASP. С начала 2016 года вдруг взялись все переписывать на .NET 4.6, а тут как раз вышел .NET Core (сырой и недоделанный), а ведь остальные .NET-ы прикажут долго жить к моменту, когда проект будет полностю переписан. Как быть камрады?
ZOXEXIVO
21.10.2016 00:53+8Вашему enterprise так необходим .NET Core? Вы думаете, там другой диалект C#?
robert_ayrapetyan
21.10.2016 15:33Еще хотят засунуть все это в Azure, и типа там .NET Core более применим (во всяк. случае MS об этом кричит, маркетинговая замануха или реальность?)
ZOXEXIVO
21.10.2016 15:57.NET Core это не новый C# и ничего «учить» там не нужно. Просто другой способ дистрибуции вашего приложения, такое микроядро с подключаемыми модулями.
Основная сложность в портировании — исключение Windows-специфичных вещей из своего приложения. Если это жесткое legacy, то скорее всего все будет плохо.
В Azure очень важно кнопочкой быстро создать виртуальную машину и быстро ввести ее в действие. Windows Nano Server + .NET Core позволит за считанные секунды развернуть новую виртуалку задеплоить на нее ваше приложение, которое, к тому же, быстро начнет работать.robert_ayrapetyan
21.10.2016 16:15Ну с C# то как раз понятно, непонятно на чем щас переписывать classic ASP проект с нуля — на .Net Core или .Net 4.6, если все это хотят тут же засунуть в Azure?
ZOXEXIVO
21.10.2016 16:29Вам нужно просто переделать его на ASP.NET Core.
net46 или netcoreapp1.0 выбирается в конфиге.
Serginio1
21.10.2016 16:35Я уже давал ссылку на бенчмарки
Кроме того несложно перенести проект на Asp.Net Core Портирование большого проекта на .NET Core
Так или иначе .Net Core будет развиваться бОльшими темпами. За ним будущее.kekekeks
22.10.2016 01:36Так там производительность не за счёт .NET Core вместо .NETFX, там производительность за счёт libuv и более легковесного пайплайна обработки запросов.
Serginio1
22.10.2016 11:17Ну там весь Asp.Net Core переработан Microsoft.AspNetCore.Server.Kestrel
kekekeks
22.10.2016 19:53Я вам по секрету скажу, что Kestrel — это всего лишь OWIN-совместимый сервер и ASP.NET Core можно при желании завести поверх IIS integrated pipeline (прямо как старый, да)
Serginio1
22.10.2016 20:42По ссылочке
AspNetCoreModule
Хостирование приложений ASP.NET Core на IIS происходит с помощью нативного модуля IIS под названием AspNetCoreModule, который сконфигурирован таким образом, чтобы перенаправлять запросы на веб-сервер Kestrel. Этот модуль управляет запуском внешнего процесса dotnet.exe, в рамках которого хостируется приложение, и перенаправляет все запросы от IIS к этому хостирующему процессу.
При этом
Публикация на IIS
Традиционно веб-сервер IIS (Internet Information Services) применялся для развертывания веб-приложений. Для хостирования веб-приложений ASP.NET Core также может применяться IIS, только в отличие от предыдущих версий ASP.NET теперь его роль будет сводиться к прокси-серверу. Хостирование приложений ASP.NET Core на IIS происходит с помощью нативного модуля AspNetCoreModule, который сконфигурирован таким образом, чтобы перенаправлять запросы на веб-сервер Kestrel. Этот модуль управляет запуском внешнего процесса dotnet.exe, в рамках которого хостируется приложение, и перенаправляет все запросы от IIS к этому хостирующему процессу.
При этом пул приложения выбирается
В открывшемся окне для параметра Версия среды CLR .NET установим значение Без управляемого кода:
kekekeks
22.10.2016 20:59+1Я рад за ваши ссылки. Теперь рекомендую прочитать код и узнать, как всё вышеописанное внутри работает.
Serginio1
22.10.2016 21:02Спасибо. Попробую.
kekekeks
22.10.2016 21:19Начать можете с взгляда на реализацию
WebHostBuilderKestrelExtensions::UseKestrel, далее посмотреть, что такоеIServer, затем изучить документацию, а конкретно раздел "Run ASP.NET Core on an OWIN-based server". после чего осознать, что реализация IServer без проблем делается на базеMicrosoft.Owin.Host.SystemWeb, так как предоставляет точно такой же стандартный OWIN-овскийDictionary<string, object>со всем необходимым.
Выглядит примерно так:
Реализация IServer с кодом для настройкиpublic static class SystemWebAspNetCoreShim { public static IAppBuilder UseAspNetCore(this IAppBuilder builder, IWebHostBuilder hostBuilder, bool continueOn404) { var server = new Server(continueOn404); hostBuilder.ConfigureServices(services => services.AddSingleton<IServer>(server)); hostBuilder.Build(); hostBuilder.Start(); builder.Use<Middleware>(server); return builder; } class Middleware { private readonly AppFunc _next; private readonly Server _server; public Middleware(Func<IDictionary<string, object>, Task> next, Server server) { _next = next; _server = server; } public Task Invoke(IDictionary<string, object> environment) { return _server.HandleRequest(environment, () => _next(environment)); } } class Server : IServer { private readonly bool _intercept404Errors; public void Dispose() { } public Func<IDictionary<string, object>, Func<Task>, Task> HandleRequest { get; private set; } public Server(bool intercept404Errors) { _intercept404Errors = intercept404Errors; } public void Start<TContext>(IHttpApplication<TContext> application) { HandleRequest = async (env, next) => { var features = new FeatureCollection(new OwinFeatureCollection(env)); var context = application.CreateContext(features); try { await application.ProcessRequestAsync(context); } catch (Exception ex) { application.DisposeContext(context, ex); throw; } application.DisposeContext(context, null); /*if (_intercept404Errors && owinContext.Response.StatusCode == 404) { await next(); }*/ }; } public IFeatureCollection Features { get; } = new FeatureCollection(); } }
Serginio1
22.10.2016 21:02Добавлю, что я сделал SignalR сервер на ASP.NET Core. При этом под хамарин есть клиент, а для .Net Core нет даже альфы пока. Вот ссылка SignalRSample.Web/
https://chsakell.com/2016/10/10/real-time-applications-using-asp-net-core-signalr-angular/
https://radu-matei.github.io/blog/aspnet-core-mvc-signalr/kekekeks
22.10.2016 21:26+1А в чём проблема "сделать SignalR сервер", если он изначально хостится на OWIN? Это делается ровно в 1 (одну) строку:
app.UseAppBuilder(appBuilder => appBuilder.MapSignalR());Serginio1
22.10.2016 21:42https://github.com/aspnet/SignalR-Server/blob/dev/samples/SignalRSample.Web/Startup.cs
Ну да. из вот варианты
app.UseWebSockets(); app.UseSignalR<RawConnection>("/raw-connection"); app.UseSignalR();
Serginio1
22.10.2016 11:47И главное, что им не нужна была совместимость с ASP.NET Core сегодня: за и против
Платформе ASP.NET более 15 лет. Кроме этого, на момент создания System.Web содержала большое количество кода для поддержки обратной совместимости с классическим ASP. За это время платформа накопила достаточное количество кода, который просто больше уже не нужен и устарел. Microsoft встала перед непростым выбором: отказаться от обратной совместимости или анонсировать новую платформу. Они выбрали второй вариант. Одновременно с этим они должны были отказаться и от существующего runtime. Microsoft всегда была компанией, ориентированной на создание и запуск всего и вся на Windows. Существующая ASP.NET не был исключением. Сейчас ситуация сильно поменялась: значительное место в стратегии компании стали занимать Azure и Linux.
ASP.NET Core – это работа над ошибками классического ASP.NET MVC, возможность начать с чистого листа. Кроме этого, Microsoft также стремится стать такой же популярной, как Ruby и NodeJS среди более юных разработчиков.
— Что значит для нас переход на новую платформу?
— .NET Core не содержит многих компонентов, к которым мы привыкли. Забудьте про System.Web, Web Forms, Transaction Scope, WPF, Win Forms. Их больше нет.
zenkz
21.10.2016 00:54+2Верной дорогой идёте товарищи!
.Net 4.6 является наиболее оптимальным вариантом на сегодняшний день.
Проверенный и надёжный. Ведь ещё не понятно, приживётся ли .Net Core или нет. И стабильная версия с исправленными ошибками появится не раньше чем через 1-2 года. Раз классический ASP в вашем проекте прожил 16 лет, то не думаю, что .Net 4.6 проживёт меньше. Очень уж много кода уже написано на .Net. А через 10-15 лет можно будет ещё раз переписать уже на .Net Core 4 или 5 (или какая там версия будет через 10 лет).robert_ayrapetyan
21.10.2016 03:38Не получится ли так, что поддержка .Net 4.6 полностью схлопнется через пару лет?
gandjustas
21.10.2016 04:45+2Уже ведутся разговоры о том, то надо все версии .NET FW привести к одному знаменателю. Поэтому будет один базовый .NET и разный набор либ в зависимости от платформы — Windows\Portable\Linux\Xamarin\еще_что_то.
Serginio1
21.10.2016 10:49+1Ну ждать немного осталось https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/
А то с этими профилями одно мучение. Кроме того пока инструменты в pre/ Ждемс .NET Core Tooling in Visual Studio “15”
Кстати Announcing the October 2016 Update for .NET Core 1.0
Serginio1
21.10.2016 10:44Ну и сейчас уже Asp.Net Core быстрее обычного Asp.Net причем в разы https://github.com/aspnet/benchmarks
Master_Dante
21.10.2016 15:06Посмотрел вашу ссылку и удивился. Есть там какой то Netty который еще быстрее в три раза. Спасибо за ссылку буду копать.
Serginio1
21.10.2016 15:09Ну не в 3 и на Plain Text with HTTP Pipelining
Для Plain Text всего 1.4Master_Dante
21.10.2016 16:35Да я посмотрел там ява, а я ее не перевариваю )). Если уж и зайдет об этом речь, мы просто напишем свой web сервер, который будет эффективнее управлять подключениями.
korzh
21.10.2016 11:22Если это classic ASP, то значит это некое веб приложение.
В таком случае идеальный подход сейчас — писать на ASP.NET Core over .NET Framework 4.6 (но не .NET Core).
Если потом понадобится кросс-платформенность — то, думаю, перенос на .NET Core можно будет через некоторое время осуществить простым добавлением target платформы и перекомпиляцией.
zenkz
21.10.2016 00:42+6Я люблю .Net за его «монолитность» и удобные инструменты.
Преимущество «монолитности» является в том, что 80-90% того, что мне нужно реализовать, я могу реализовать с использованием стандартных классов и средств языка, а не искать сторонние плагины (которые могут быть криво написаны или с плохой документацией).
В отличии от Java и того ада, что творится в JS frontend-разработке, я могу запустить Visual Studio, нажать «Create Project» и нажать «Run». И веб-приложение запустится. Не нужно настраивать всякие конфигурации, подключать сборщики и менеждеры пакетов и т.д.
Синтаксический сахар C#а шикарен. Язык хорошо стандартизирован и документирован и на нём приятно писать.
.Net, как и Java, ещё долго не уйдут с рынка Enterprise-решений и будут сильны для серверной части приложений. Движение в сторону кросс-платформенности также даёт повод для оптимизма.
Жду выхода следующей версии .Net Core и надеюсь что основные детские болезни будут в ней устранены и он будет годен для Enterprise-разработки.
ad1Dima
21.10.2016 04:17-1что 80-90% того, что мне нужно реализовать, я могу реализовать с использованием стандартных классов и средств языка
В случае не монолитности то же самое можно использовать с помощью стандартных плагинов. Хотя на самом деле сейчас так и есть. и я не понимаю претензии в статье.gandjustas
21.10.2016 04:51+2В случае не монолитности то же самое можно использовать с помощью стандартных плагинов
Это неправда. Посмотри на C++ — до сих пор в каждом фреймворке свой класс строк, и все эти строки не совместимы между собой.
ad1Dima
21.10.2016 04:55Просто строки нужно в микроядро, монолитность/модульность тут не причём. Когда делали C++ полагали, что массива символов для строк более чем достаточно. А потом пришёл UI и понеслась...
gandjustas
21.10.2016 05:23Ну по такой логике много что нужно в микроядро:
- строки
- работа с сетью и веб-клиент
- асинхронность и многопоточность
- сериализация
Причем эти все вещи взаимосвязаны.
Собственно в .NET так и сделали — включи все это в "монолитное ядро", а в С++ до сих пор разброд и шатание.
ad1Dima
21.10.2016 05:39-1Строки, многопоточность и асинхронность да. (асинхронность — вообще синтаксический сахар, так-то.)
Вебклиент лучше стандартным модулем, сереализацию тоже. А то получается сейчас в .net 3 или 4 разных сериализации (xml, json, runtime), а большинство пользуется только json.net.
Причем эти все вещи взаимосвязаны.
связ не полная. Явно прослеживаются доли графа.
ad1Dima
21.10.2016 05:44Но на самом деле, что-то мне подсказывает, что Рихтер имел в виду не библиотеки, которые и так разделены, а саму исполняемую среду.
TreyLav
21.10.2016 02:24Что может быть лучше C#, если ваша целевая платформа — Windows only, да ещё с GUI? C# — хороший язык с как минимум одной чёткой нишей, с чего бы ему умирать?
geekmetwice
21.10.2016 04:04-9Да уж, статейка — даже не рекламный наброс, а какие-то расхожие мифы, собранные весьма посредственным программистом. Перечислять — автор сгорит со стыда за свою пургу:
> Она объединяла «под одной крышей» несколько языков программирования, что было в новинку для того времени.
Ни разу не новинка. Просто скомпилённая DLL-ка в Delphi и заюзаная в VB — ровно то же, только «под одной крышей» Венды.
> программисты начали создавать свои приложения на тех языках, которые знали лучше всего
А если быть совсем точным, то ТОЛЬКО на тех языках, которые были написаны под .NET; Фактически, юзабельных языков было всего ДВА — школотронский васик и сишарп.
> которые лучше подходили для решения своих задач.
Чего?? Чем васик для «своих задач» лучше/хуже C#? Что за бестолковая привычка лепить «язык для своих задач»! Мы используем ЯОН — внимательно расшифруйте эту аббревиатуру и не позорьтесь этим мемом «язык — задачи».
> Сложно переоценить роль такого нововведения, как веб-сервисы
Да не сложно! Фуфло это проприетарное. После них ещё пяток технологий выкатили, из последних велосипедов — WCF. Ну и какова тут «роль веб-сервисов»? И без них было что юзать — Corba, TCP.
> тесная интеграция ASP.NET с Windows IIS… критики со стороны сообщества
Да ладно! Критики ОТ КОГО? Красноглазых линуксоидов? Коммерческие разрабы спокойно сидели в нише Windows и никто даже не думал куда-то валить.
> Сейчас это может кому-то показаться смешным, но тогда качественный инструмент для создания GUI был в новинку.
Серьёзно? Да уж… если во времена Delphi автор ходил в детсад — тогда да, можно простить такой пробел в знаниях.
> разработчики пошли навстречу поклонникам других ОС. Так, например, в сообществе open source появился проект Mono
Не надо опять гнать пургу! Никакие разработчики не шли навстречу — микрософт был анально огороженной средой, а Моно — энтузазистский проект Мигеля, НИКАК не поддерживаемый разработчиками MS.
> который был официально признан реализацией .NET на Unix-подобных операционных системах
Опять бестолковщину пишете! Моно НЕ ЯВЛЯЕТСЯ официальной и поддерживаемой платформой! .NET Core — да, а мексиканское поделие — нет.
> Главная претензия критиков – это нерациональное использование памяти системы.
Ха-ха! ДА ЛАДНО?! :) Вот уж чего никогда не считали, так это память под дотнет — она просто есть и по-умолчанию её навалом.
Фактически, дотнет даже не за что критиковать — он идеален с точки зрения среднего прогера, пишущего для венды. Критиканы прибегают в основном с Линуксов, которым уже прилетело сипиписными граблями по всем местам и они мечтают об удобном инструменте типа VS/C#.
Ну и в довершении этой смехотворной статьи, мои личные ответы: Перспективы у .NET ОЧЕНЬ МРАЧНЫЕ. Если «обычный» дотнет — вполне себе юзабельная платформа, то кому обздался Core — ещё большой вопрос. На венде он точно не нужен, кто хотел скоростей/памяти — давно подружились с С++. На Линуксе — тем более, там одних языков ДЕСЯТКИ — пиши-не хочу. И главное — поганая привычка MS портить то, что уже хорошо сделано. Например, WinForms. Было скучно — запилили неуклюжего монстра WPF. Поддержку Win XP похерили ещё в .NET 4.5 (хотя казалось бы, что умного понаписали для 7, чего нельзя сделать в XP??). Silverlight — в могиле. То же ждёт и Core — потратят деньги и ресурсы на очередной всемогутер, а потом окажется, что юзают его 2.5 инвалида из самого же MS. А отрасль и винда в частности опять затормозится в развитии. Эпик фэйл с Win 10 ещё впереди!
Эх, гнусные времена ждут мелкомягких танцоров-диско!gandjustas
21.10.2016 04:49+11Делфи-батхерт детектед.
Делфи сдох. C# — новый делфи и это было изначальной целью.
tangro
21.10.2016 10:27-4Делфи сдох. C# — новый делфи и это было изначальной целью.
Тоже сдохнуть через пяток лет?
aikixd
21.10.2016 11:45+2то кому обздался Core — ещё большой вопрос. На венде он точно не нужен, кто хотел скоростей/памяти — давно подружились с С++.
Бред. На шарпах сейчас игр развелось хоть обавляй. Он проще, лучше отлаживается и более предсказуем. И для этих игр любой школьник может написать аддон и не угробить всю систему. На сях инди сцены бы просто не появилось.DistortNeo
21.10.2016 13:18-1Минус только в потреблении памяти. Всё-таки неприятно видеть, когда игра потребляет 11 гигабайт памяти.
Anarions
21.10.2016 16:18+1Не видел такого ни разу в жизни.
denismaster
21.10.2016 16:23Значит вам повезло и вы не играли в Space Engineers=)
aikixd
21.10.2016 16:53+1Дело в инженерах а не среде. С тем же успехом вы можете десятком строк заплодить все пространство Objectами на 128 гигов. Так игра устроена.
denismaster
21.10.2016 17:32Я категорически с вами согласен, что там проблема в самой игре, а не в дотнете) Я просто привел пример игры, которая легко кушает 11 гигов памяти)
DistortNeo
21.10.2016 19:43А зря, столько памяти потребляют последние новые игры (на максимальных настройках): GTA V, Mirror's Edge Catalyst. Из игр на .NET могу привести Cities: Skyline, которая вполне может и 7-8 гигов откушать.
Последние 5 лет мне за глаза хватало 16 гигабайт памяти (игры + разработка + виртуальные машины + обработка изображений на одном компе), сейчас же что-то захотелось уже 32 или даже 64.
Master_Dante
21.10.2016 15:13+1Друх .Net Core сделали опенсорс а это значит бессмертие. Я уже на нем пишу ;)
ZOXEXIVO
21.10.2016 09:50+4Модные Go, Swift программисты конечно скажут что .NET не моден
S_A
21.10.2016 11:00+4Внезапно тут открыл для себя F# (постоянно пишу на C#), и теперь вообще не планирую куда-то переходить (хотя на том же Swift писал, на Java тоже, и на node.js периодически пишу).
Языки и среда будут полагаю будут развиваться, сообщество не уменьшается, и с каждой новой технологией по типу Xamarin добавляются новые пользователи платформы и её производных. Nuget вообще находка, репозиторий не хуже npm по качеству пакетов (попадается конечно фуфло и там и там), хотя и не по количеству.
В чем по-моему имхо плюсы? C# сам по себе я не считаю мегаплюсом, и уж тем более его «сахар» (что спорно, но не буду об этом). Сам по себе .net тоже не особо уникален или примечателен. Примечательно то, что если node.js хорош во всем, что связано с вебом, html (в том числе для мобил), и пусть даже десктопом (electron), то ms — это в первую очередь десктопная экосистема (и с Xamarin теперь еще и мобильная). И я не вижу ничего плохого, если бы XAML работал на Linux. Не так уж плохо у ms всё спроектировано, не хуже чем в Java-мире или Python-мире.
А, да. F#… есть холивары насчет языков с отступами. Удобство в том, что легко оборачивать код в подфункции, и подобные манипуляции делаются обычным (ctrl+)shift+tab, не надо ставить скобки :) А если серьезно, то надеюсь у F# будет большое будущее. Писать нужно очень мало кода по сравнению с С# до достижения того же эффекта. В голове правда держать нужно больше контекста, но к этому привыкаешь.
Pakos
21.10.2016 11:06asm умер, Delphi умер, .Net умер… а посмотришь вокруг — работают эти живые мертвецы.
quwy
21.10.2016 11:23+1Что-то мне это напоминает…
Бешенная популярность на определенном этапе, но как-то постепенно все угасает.
Все чаще проскакивают фразочки «не модно» и типа того.
Хоть популярность и падает, стек жив и вроде неплохо развивается.
Вот уже пошли жизнеутверждающие статьи, основной мотив которых: ЖИВ!
А дальше будут только вакансии по саппорту легаси и клеймо «мамонт».
Короче, добро пожаловать в клуб, дотнетчики :)
Disbeleiver
21.10.2016 11:23.NET — вполне модная платформа в игрострое благодаря Unity (и CryEngine в бесплатные подтянулся).
Mamboking
21.10.2016 11:23+1Очень странная подборка очень странных мнений. Посмотрите лучше на рынок труда — спрос на .net программистов есть, достаточно большой и стабильный, значит и проекты на .net востребованы.
gbr
21.10.2016 11:23Я на дотнете лет 15, у меня практически руки под дотнет заточены. Но последний раз хорошую позицию я нашел за 1.5 года! Это при том, что лет 5 назад я проходил по 9 собеседований в неделю. Сейчас я на Java+Spring+Maven. В России ИТ движет госзаказ, а здесь импортозамещение в разгаре — уход в сторону java и open source, особенная неприязнь к Microsoft (мне так кажется). Дотнет будет жить во всем остальном мире, поскольку он прекрасен, но не в России. Мне удавалось на дотнете иной раз в одиночку создавать большие системы, которые на Java можно сделать за те же сроки только командой и с худшим качеством. Кстати, откуда этот график? Он совсем не отражает действительность. Вы давно на hh заходили? Сейчас дотнет в упадке, трудно найти Java разработчика (может все нарасхват?). А в конечном счете всех уделает JavaScript
ZOXEXIVO
21.10.2016 12:46+1Вы пропустили важный этап в жизни .NET и теперь он тоже попадает в категорию «Импортозамещения»
gbr
22.10.2016 11:14Вы имеете в виду Core? Это бесполезно, поскольку на .NET и C# навсегда наклеен нелюбимый бренд Microsoft. Вы думаете я не был бы рад использованию .NET? Чиновникам не объяснить, что Core работает под Linux и что под .NET полно open source — бесполезно: ".NET — это Microsoft? Да? Нафиг его! "
DistortNeo
22.10.2016 21:39+1Ну не знаю, вот я сейчас разрабатываю серверную часть для госзаказчика. Заказчику все равно, на чём написано, ему главное, чтобы работало под Linux. Поэтому разработка ведётся на C# из соображений удобства разработки и отладки.
gbr
23.10.2016 16:14-2Искренне за Вас рад, держите нас в курсе. Но сильно не кричите о том, что у вас все на шарпе, мало ли что.
marshinov
23.10.2016 20:59У вас какие-то другие чиновники и другая Россия. У Барс Груп, тот что входит в тройку крупнейших интеграторов в B2G и был недавно приобретен Ростехом большая часть разработки на .NET.
dmitry_dvm
21.10.2016 12:01+1Что-то можно, а что-то вечно. Шарп прекрасный язык. У дотнета отличная инфраструктура, отличные инструменты. Где сейчас модный CoffeeScript? Некогда гремевший jQuery тоже на грани забвения.
gbr
21.10.2016 12:42Не путайте плз CoffeScript, jQuery с JavaScript. А насчет уделает — время лучший судья, вспомните мои слова потом. А вот еще: http://stackoverflow.com/research/developer-survey-2016
Кто до сих пор не понимает, тот и дальше будет испытывать проблемы с поиском разработчиков и работы.Anarions
21.10.2016 16:23Там опросник с множественным выбором. Естественно все кто связан с вэбом, или гибридными приложениями, помимо «основного» языка указали javascript. Из «серьёзных» языков на первом месте, как раз, C#
chumakov-ilya
21.10.2016 12:12+3Заголовок в лучших традициях желтой прессы. Не затруднит ли вас пояснить, кто считает .NET немодным?
ad1Dima
Странные вбросы про потребление памяти. В сравнении с чем? с С++? ASM? Мне казалось, что эта тема была закрыта лет 10 назад.
Dywar
Когда в ноутбуке на редкость было 4гб :)
Сейчас магазин DSN ноутбуков 1051шт, из них с памятью 4гб и выше — 857шт, а это 82%.
ad1Dima
Вопрос даже не в увеличившимся количестве памяти в компах, а том что на своём рынке .NET кушает нормально. Да на рынке программаторов и битов это непотребно много, но когда мы говорим о прикладном ПО, быстрой разработке и длительной поддержке, кто ест принципиально меньше?
tangro
Ну, справедливости ради — сравните потребление памяти браузером ну или модной игрушкой в те времена и сейчас.
Pakos
Вы тоже пишете софт так что сервер приходится перезагружать из-за исчерпания памяти? А то были такие товарищи, считавшие что память бесконечна.
Dywar
Каждый день по терабайту отъедаю :)
Дело не в том как кто пишет, что и зачем. А в том что острота вопроса уже не та что 10 лет назад.
Если CRL потребляет чуть больше памяти чем некоторым хотелось бы, возможно используется не тот инструмент для решения поставленной задачи.
Хотите рассказать как работает ГЦ, послушаю :)
Возможно в книгах и докладах с конференций что то важное упустили и я не в курсе.
zenkz
Да, зря на .Net бочку катят за использование памяти. К тому же часто проблема использования памяти — это не проблема языка, а проблема конкретного кода и алгоритмов.
Посмотрите к примеру на любой современный браузер. Firefox с радостью съедает 2-3 Гб памяти всего с 10-15 открытыми вкладками. Вот уж где нужна оптимизация.
Dark_Daiver
>К тому же часто проблема использования памяти — это не проблема языка, а проблема конкретного кода и алгоритмов.
Ну строго говоря нет. Язык может быть построен на принципах, которые трудно или невозможно реализовать без оверхеда (или грязных трюков).
Гипотетический язык с «честной» динамической типизацией будет априори проигрывать гипотетическому языку со статической типизацией (по производительности и потреблению памяти), к примеру.