Если коротко, то разработка модульных приложений в RC2 очень упрощена. Благодаря новой возможности «части приложения» (application parts), вы легко можете разделить свой большой проект на несколько более мелких и затем свободно компоновать их. Особенно это удобно при работе с областями (areas), которые и так изолируют набор контроллеров, представлений и прочих ресурсов — каждую область теперь можно выделить в отдельный проект. Насколько я понял (в частности, из aspnet/Mvc#4089), реализация ориентирована именно на разделение большого проекта на маленькие и только в части MVC. Остальное все-таки придется писать самому.
Реализация
Для примера, создадим небольшое приложение и посмотрим, как все работает (предполагается, что вы уже зашли сюда и установили все, что нужно). Итак, создаем проект:
На следующем шаге выбираем «Веб-приложение», чтобы Visual Studio создала для нас готовое к тестированию приложение:
Вот и все. Теперь запустим наше новое приложение:
Я не буду останавливаться на структуре проекта и на отличиях структуры от того, к чему мы привыкли в RC1. При желании, можно посмотреть вот это.
Теперь добавим еще один проект в наше решение, на этот раз библиотеку классов:
Т. к. мы хотим посмотреть на работу контроллера и представления из нашей сборки, добавим в файл project.json ссылку на MVC. Также нам необходимо, чтобы представления в этом проекте были добавлены в сборку в виде ресурсов. Это делается при помощи соответствующей настройки в разделе buildOptions файла project.json. В результате получим такой файл:
{
"buildOptions": { "embed": [ "Views/**" ] },
"dependencies": {
"Microsoft.AspNetCore.Mvc": "1.0.0-rc2-final",
"NETStandard.Library": "1.5.0-rc2-24027"
},
"frameworks": {
"netstandard1.5": {
"imports": "dnxcore50"
}
},
"version": "1.0.0-*"
}
Теперь создадим в нашем проекте новый контроллер с единственным методом (для единообразия файл с классом контроллера желательно поместить в папку Controllers, хотя это и необязательно):
public class ModuleAController : Controller
{
public ActionResult Index()
{
return this.View();
}
}
Теперь в папке \Views\ModuleA создадим представление Index.cshtml с таким содержимым, которое вам нравится.
Проект готов. Соберем его. В папке с проектом появится папка bin (как в прошлых версиях ASP.NET), а в ней — наша сборка. Осталось только рассказать о ней основному приложения.
Откроем класс Startup проекта нашего приложения и перейдем к методу ConfigureServices. Первым делом загрузим нашу сборку с контроллером и представлением:
Assembly assembly = AssemblyLoadContext.Default.LoadFromAssemblyPath(@"абсолютный путь к сборке");
Далее, добавим загруженную сборку в качестве части приложения в MVC:
services.AddMvc().AddApplicationPart(assembly);
Практически все. Если сейчас запустить приложение и перейти по адресу /modulea, мы получим исключение: InvalidOperationException: The view 'Index' was not found. Чтобы объяснить MVC, что искать представления необходимо и внутри нашей сборки, добавим соответствующий провайдер файлов в настройках Razor. Модифицируем предыдущую строчку кода, чтобы получилось вот так:
services.AddMvc().AddApplicationPart(assembly).AddRazorOptions(
o =>
{
o.FileProviders.Add(new EmbeddedFileProvider(assembly, assembly.GetName().Name));
}
);
Наше приложение, состоящее из двух частей, готово. Запустим его, перейдем по адресу /modulea:
Очень здорово. Еще в RC1 для этого потребовалось бы больше кода. Но этого достаточно только до тех пор, пока вы не захотите использовать строго типизированные представления. Если добавить класс модели вида в наш проект, и затем указать его в качестве модели для нашего представления, во время выполнения мы получим исключение: The type or namespace name 'ModuleA' does not exist in the namespace 'AspNetCoreApplicationParts'. Связано это с тем, что наша сборка не входит в набор сборок, в котором Razor ищет типы при компиляции представлений. К счастью, есть достаточно простой способ это исправить. Кроме того, в ближайшем будущем в этом шаге не будет необходимости, т. к. сборки, добавленные как части приложения, будут участвовать в Razor-компиляции автоматически.
Модифицируем вызов функции AddRazorOptions, которую мы использовали на предыдущем шаге, таким образом:
.AddRazorOptions(
o =>
{
o.FileProviders.Add(new EmbeddedFileProvider(assembly, assembly.GetName().Name));
Action<RoslynCompilationContext> previous = o.CompilationCallback;
o.CompilationCallback = c =>
{
if (previous != null)
{
previous(c);
}
c.Compilation = c.Compilation.AddReferences(reference);
};
}
);
Осталось объявить переменную reference где-то перед загрузкой сборки:
PortableExecutableReference reference = MetadataReference.CreateFromFile(@"абсолютный путь к сборке");
Вот и все. Теперь мы можем использовать нашу модель вида. Запустим приложение и перейдем по адресу /modulea:
Кстати, еще в RC1 можно было использовать предварительную компиляцию представлений и не иметь проблем с разрешением типов моделей видов во время выполнения. К сожалению, в RC2 предварительная компиляция не поддерживается (насколько я понял, из-за сложности реализации), но в будущем будет возвращена.
Результат
Пожалуй, application parts — именно то, чего давно не хватало ASP.NET. Я потратил много времени, чтобы добиться аналогичного результата в предыдущих версиях (еще до ASP.NET Core). Надеюсь, приведенного примера вполне достаточно, чтобы начать использовать эту возможность. И спасибо ребятам из нашего чата в Gitter, вместе с которыми мы разбирались с RC2.
Весь проект целиком (в немного упрощенном виде) доступен на GitHub.
Комментарии (66)
forcewake
21.05.2016 20:13А могли бы описать плюсы такого решения? Какие бенефиты вы получаете при использовании application parts. Спасибо.
artem_b89
21.05.2016 22:36+1Использование контроллеров, вью-компонент, хелперов из разных сборок. Можно было и раньше, но Application Parts даёт больше возможностей для настройки модулей приложения, например, из одной сборки можно использовать контроллеры, но не использовать вью-компоненты. Соответственно, для доступа к контроллерам находящимся в другой сборке, нужно эту сборку загрузить и добавить в application parts, если нужны только контроллеры, то добавить только контроллеры.
DmitrySikorsky
21.05.2016 22:45+1Не совсем понятно, плюсы в сравнении с чем. Если с предыдущей версией (RC1 и ранее), то основной плюс — значительное уменьшение объема кода, который необходимо написать, чтобы использовать контроллеры и представления из других сборок, на которые нет явных ссылок в project.json. Вы просто загружаете сборку и говорите MVC брать это все оттуда вызовом пары функций (а в скором будущем — одной функции, насколько я понял). Например, из моего проекта можно будет удалить вот этот класс, а также и вот этот. Если говорить о преимуществах модульных приложений вообще, то в крупном проекте очень удобно, когда различные разработчики (или команды) работают на различных проектах (например, слой доступа к данным, слой сервисов, фронтенд, бекенд). Не говоря уже о различных плагинах и т. п.
DmitrySikorsky
21.05.2016 23:00+2Вдруг еще вспомнил, как мучились люди (и на какие шли ухищрения), которые хотели вынести область (area) в отдельный проект. В итоге, большинство простых решений были очень сомнительным, вроде копирования проекта с областью в папку Areas основного проекта и так далее. А теперь это делается совершенно просто. Также я помню сколько часов у меня ушло, чтобы заставить Razor в MVC5 компилировать представления, которые использовали модели видов из внешних сборок. В общем, это действительно здорово, что теперь все это в прошлом.
dobriykot
22.05.2016 14:41+1+ к Area. Сам мучился с этим, так и не смог заставить работать прозрачно и без костыления на каждом шагу. Когда у приложения большие части, их удобно выделить в отдельные модули, которые может писать другая команда. И использовать там свои технологии, другие фреймворки и т.п.
ofigenn
22.05.2016 15:52+1Почему не MEF? Только из-за Razor?
DmitrySikorsky
22.05.2016 17:15+1Мне нравится MEF, я использовал его для разработки модульных веб-приложений на предыдущей версии ASP.NET и MVC. Теперь, насколько я понимаю, он позиционируется как решение для настольных приложений (вроде Visual Studio, где он и применяется). Он не кросс-платформенный, да и вообще, уже не вписывается в новую концепцию, поэтому, думаю, и остался за бортом.
Razaz
22.05.2016 20:28Он всегда и позиционировался для десктопа. С Asp.Net начинался форменный ужас если у вас еще и вьюхи раскиданы по разным сборкам. Начинались танцы с добавлением сборок в PreApplicationStart.
В результате Nuget + Autofac решают все проблемы самым лучшим образом.
mtt
23.05.2016 10:18Ну наконец то MVC допилили до вменяемого состояния. Не понимаю, как можно было писать серьезные проекты без этих parts. Когда релиз, есть информация?
DmitrySikorsky
23.05.2016 10:52Я, к сожалению, не знаю. Но судя по всему, таких серьезных изменений больше не будет.
DmitrySikorsky
24.05.2016 12:27UPD: судя по всему, в конце июня ожидается релиз.
Flaksirus
24.05.2016 12:58Ага, релиз Asp.net core. Но не всего целиком, инструменты dotnet будут только в превью 2, а ведь на них самое большое колличество жалоб…
gturk
23.05.2016 11:13+3Не понимаю, как можно было писать серьезные проекты без этих parts.
Ну я, например, всю более-менее значимую логику всегда выносил в отдельные проекты (старые добрые dll), а сам MVC проект — это сугубо принять запрос от пользователя и нарисовать ответ. И никаких сложностей с одновременной работой нескольких человек над одним проектом не возникало
Razaz
23.05.2016 11:21+1Легко) Если у вас фронт — SPA, то вам это все как-бы и не нужно. Можете посмотреть Orchard и Orchard2 в плане тотальной модульности. Даже сборка расширений из исходников в рантайме есть.
mrigi
23.05.2016 15:26Разбить на мелкие сервисы, минимально связанные друг с другом? Тут больше вопрос: а есть ли смысл всё пихать в один проект и правильно ли это.
Scratch
После того как они убрали project.json и опять вернулись к старым файлам проектов csproj, а dnx теперь dotnet, мне кажется, они вообще слабо представляют, что делают
robert_ayrapetyan
Титаник пытается всплыть, обложившись спасательными кругами из Open-Source, но кажется они лет на 10 опоздали уже.
robert_ayrapetyan
Чего возбудились? MS давно пинками выгнали со всех горячих рынков (смартфоны, браузеры, бекенд, поисковики etc).
Единственное, где MS все еще (пока) доминирует — десктопы, только тренд этот падает постоянно вот уже много лет (десктопы стали лишним предметом интерьера для домохозяек в США и Азии, печалька :(), а на мобильный рынок им вход уже заказан.
И МС, конечно, все это прекрасно понимают, но вот эти ихние встраивания нейтивной поддержки Linux-apps в Windows 10, потуги пропихнуть Azure в широкие массы (опять же, обвешавшись со всех сторон сервисами и брендами из мира Open Source (какая ирония судьбы хаха)) — хватание утопающего за соломинку… И да — лет 10 назад у них все могло еще получиться не так печально.
overtest
Так и не понял из комментов выше, чем разработка в ASP.NET MVC уступает другим фреймворкам и в чем именно они опоздали на 10 лет.
robert_ayrapetyan
Да хотя бы вот тем, что из всех пользователей хабра «ASP .NET» интересуется пара процентов людей, из которых реально верят в будущее этого фреймворка пара десятков (это видно по реакции на мои комменты выше). Если у фреймворка больше нет сообщества, то он умирает. Более того, в ASP.NET MVC не верят и сами его создатели, именно поэтому и началась вся эта судорожная возня с .NET Core, которая разродится более-менее стабильным релизом (и это тоже кстати еще под большим вопросом) не раньше, чем через год, когда в умирающией экосистеме останется еще более жалкий процент разработчиков.
overtest
Я не в курсе, как посмотреть процентное соотношение интересующихся на Хабре, да и незарегестрированных пользователей, читающих Хабр куда больше, чем зарегистрированных. И почему популярность фреймворка вы мерите только Хабром? Лично я особо не задавался этим вопросом, но после ваших слов решил сравнить кол-во вакансий на некоторых сайтах с Php-вакансиями:
hh.ru (по Москве): ASP.NET = 318; PHP = 848;
linkedin.com (USA): ASP.NET = 9952; PHP = 780;
lupwork.com: ASP.NET = 746; PHP = 7433;
Как-то не похоже на умирающий фреймворк.
Кстати, у вас есть опыт разработки с ASP.NET MVC?
robert_ayrapetyan
Хабр достаточно репрезентативнен, мненеи основано не только на данных с хабра (см. ниже).
По линкдин — у вас ошибка где-то в запросе, поиск отсюда по США выдает 9937 результатов, а ASP .NET — 6814, но все это жонглирование цифрами, никак не показывает реальное положение вещей на рынке (например, разработчики в резюме обычно указывают технологии, с которыми работали и 10 лет назад, поэтому ASP .NET набирает много очков на сайтах вакансий), да и вообще сравнивать фреймворк (ASP .NET) и язык (PHP) несколько некорректно.
Реальная картина представлена здесь, опять же, не забываем что львинная доля сайтов на ASP .NET создавалась 10-15 лет назад. Но все это детский шалости по сравнению с этим…
Господа минусующие, есть что сказать по последнему графику?
overtest
Поскольку вы не сказали, с чем более корректно сравнивать на ваш взгляд, я посмотрел график опять же Php, и не увидел сколько-нибудь более радостной картиры. Потом немного конкретизировал ваш запрос по .NET и получил несклько другой график, куда более оптимистичный.
Мой вопрос про ваш опыт разработки в ASP вы проигнорировали. Однако, графики — графиками, но неплохо бы иметь личный опыт работы с продуктом, чтобы делать какие-либо предположения.
robert_ayrapetyan
Сравнивать, хотя бы с nodejs или, на худой конец, с go.
Лично мои симпатии на стороне python и его сообщества.
По поводу оптимистичности вашего графика не согласен — он еще стремительнее «падает», чем приведенный мной (мой и ваш на одном.
Мой опыт разработки на ASP никак не связан с вымиранием данной экосистемы. Заметьте, я нигде в слова не сказал, чем .NET хуже или лучше, я просто привожу факты, ссылаясь на доступные источники.
Более конкретные замечания, самые свежие впечатления от .NET Core — это полный fail… На Ubuntu (официально поддерживаемый дистрибутив) 16 версии он вообще не заводится, никак (есть официальный баг на эту тему, кто пробовал поставить недавно, в курсе). На 14 версии после долгих переключений между новым dotnet и старым dnx, несколько раз менял enginе с mono на native (причем, пробовал много разных версий), еще два часа борьбы с импортами и несоотвествием версий в манифесте проекта и движком — и весь этот зоопарк был снесен раз и навсегда… И это называется RC2? Просто позор…
Razaz
1. dotnet — preview1.
2. RC2 для самого Core Clr и Asp.net Core.
3. Можно ссылку на баг?
Из всех языков/платформ что вы назвали конкурентов .Net нет. Только Java, но про нее что-то не упомянули.
robert_ayrapetyan
3. Вот.
Чем, например, Python, со всеми доступными модулями и фреймворками не конкурент .Net? Опять же — не хочется уводить в сторону +\- — это бесперспективно, холиварно и в данном топике, кроме еще пачки минусов от неистово минусующих мои комменты ничем не закончится. Убежден, что в статье более общего плана, например, о перспективах развития фреймворков в целом, на этом же ресурсе адептов .NET просто утопят в минусах.
У Java тоже не все так радужно. Если Гугл вышвырнет ее с Андроида, то станет совсем плохо (а Оракл сам напрашивается на такой исход).
Razaz
dotnet CLI on Ubuntu 16.04.
Он в preview. Какие к нему вопросы то?
Причем здесь минуса? Напишите Apache Cassandra или Neo4J или RavenDB на питоне, потом и поговорим про многопоточность, асинхронный IO и тд. Или может что нить повеселее с Akka, Vert.x, Orleans.
Мерять платформу минусами на хабре смешно. Это только говорит о том, на сколько то или иное комьюнити активно на определенном ресурсе.
robert_ayrapetyan
Вопросы есть по Ubuntu 14 — почему с ним все так плохо? Может вы знаете инструкцию по приготовлению простейшего hello-world web-app на базе .Net Core? Почему ни одна из инструкций в топовой выдаче гугла не работает?
И зачем писать движки БД на питоне? С асинхронным IO и многопоточностью, там, кстати, все в порядке, не хуже и не лучше чем у других.
Опять же — вопрос не в том что лучше или хуже, а что исторически просто уходит в небытие и не поддается воскрешению, а что цветет и набирает обороты. «Бесплатный, опен-сорсный, кросс-платформенный фреймворк от МС» — это чудесно, но кому это все нужно сегодня? (тем более, оно даже на альфу не тянет по качеству). Зачем вообще МС вся эта возня с Open-Source и «мы начинаем все опять»?
yara_73
Эм, не хочу вас расстраивать, но я уже несколько недель делаю приложение на базе ASP.NET Core, под OS X 10 и знаете, все отлично завелось с первого раза и работает и работает отлично, а Kestrel — пока что для меня отличная альтернатива разжиревшему IIS, но тут я субъективен, так как настроить ASP.NET Core под IIS я ниасилил, так что, кто желает увидеть, тот видит.
overtest
Python и Go более корректно сравнивать с языком C#.
robert_ayrapetyan
Ну да, это подтверждает мои выводы — C# потихоньку скатывается, Python так же плавно растет, а Go достиг пика и устаканился (что там дальше будет по нему — тяжело спрогнозировать).
overtest
График по C#
и более интересный график по ASP.NET MVC
robert_ayrapetyan
Все же если «снять очки», то будет как-то https://www.google.com/trends/explore#q=%22asp.net%20mvc%22%2C%20%2Fm%2F02_qnn%2C%20C%23&cmpt=q&tz=Etc%2FGMT%2B7 так
overtest
Не могу понять цель ваших комментариев.
Если посмотреть на эти графики, то тут, с вашим подходом, тоже все очень плохо. Можно с этими графиками пойти в соответствующие разделы хабра, или другого сообщества, и говорить людям, что их технология умирает. Но зачем? Что я этим достигну для себя, для этих людей? Кроме их раздражения и минусов к своей карме. Вы критикуете, но не предлагаете никакой альтернативы. Ваша цель критиковать или вы таким образом сами пытаетесь определиться?
У любой технологии бывают взлеты и падения, а плавное снижение еще не говорит о катастрофе, а может даже говорить о хорошей стабильности, при этом наблюдается захват части рынка другими технологиями. Или, в худшем случае, можно трактовать, как утрату актуальности в долгосрочной перспективе, но куда действительно повернет график в будущем никто не может предсказать. Лично я вижу в этом графике хорошую стабильность. А в этом — стабилизацию двух языков, хотя и с разными изначальными тенденциями.
Если ориентироваться только на растущие тренды популярности запросов, так можно всю жизнь прыгать с одной технологии на другую. Графики не дают полной картины. Всегда ли вы можете определить в какой-либо области по растущему тренду (мнению большинства) ценность предмета для своих целей и потребностей? Многие знакомые, пробующие себя в веб-разработке, выбирают php только потому, что их пугают слова «платно» и «лицензия», т.к. это первая информация, которой они владеют на момент выбора, а также под влиянием других факторов, которые необязательно склоняют в сторону оптимального выбора, например, такие как окружение. И в этом ключевом моменте MS сильно проигрывает. Даже для человека с большим опытом для того чтобы по-настоящему оценить продукт необходимо поработать с ним надо какое-то время. Если после этого вы увидите, что он значительно более удобен и производителен, чем текущий, не факт, что вы на него не перейдете, несмотря на не очень оптимистичную статистику запросов.
robert_ayrapetyan
Согласен, тренды можно истолковывать по разному. И в данном топике глупо было выступать против 20 адептов.НЕТ (а сторонники в эту тему попросту не зайдут никогда).
Единственное, в чем я уверен до конца — МС теряет свои позиции на рынке, плохо это или хорошо — не важно. Все рано или поздно кончается, даже большие корпорации приходят и уходят. МС действительно выкинули с рынка мобильных устройств, браузеров, веб-серверов, там, где МС доминировал еще каких-то 15-20 лет назад, альтернатив практически не было. То же случилось и с .NET.
Качество .NET Core действительно не выдерживает никакой критики. На Windows платформе, возможно, все работает на ура, но на официальном Linux дистрибутиве не работает даже простейший hello-world сервер. Да, я однозначно уверен, что компания (любая), которая выпускает такие продукты в паблик, и называет это RC2, находится в глубоком кризисе.
yara_73
HELLO-WORLD работает! Если он не работает у вас только — это не проблема МС, мб у вас на тестовой машине есть неполадки, расскажите, какие ошибки возникают? Если вы unix пользователь со стажем то, конечно же можете с легкостью найти логи и сказать, какие ошибки возникают, а я в свою очередь попытаюсь вам помочь
robert_ayrapetyan
Спасибо!
1. Проходим простые шаги отсюда: https://www.microsoft.com/net/core#ubuntu
Все отрабатывает без ошибок, в консоль выводится Hello World.
2. Начинаем гуглеж с целью получить рабочий hello-world HTTP сервер. Для начала идем на гитхаб, в официальный пример официального сервера:
https://github.com/aspnet/KestrelHttpServer/tree/dev/samples/SampleApp
Билдим, запускаем.
Заканчивается все выводом загадочного сообщения:
Project Microsoft.AspNetCore.Server.Kestrel does not have a lock file. (2 раза).
Баг известный — https://github.com/dotnet/cli/issues/1368. 3 (три!) месяца как висит уже.
3. Здесь уже как бы особо продолжать искать смысла нет, но из спортивного интереса продолжаем.
Продираемся через дебри клонированных статей на тему .NET 5 is dead, да здравствует core-оль! Еще пачка урлов почему .NET Core это наше все (кейворд для поиска был задан .net core web server sample).
Находим http://www.soloco.be/realtimeweb-net-asp-net-core-web-application/, но понимаем что dnx-а с нами больше нет (предварительно вдоволь наигравшись с попытакми заставить что-то работать хотя бы со старым движком).
Пропускаем статьи по созданию проектов из темплейтов VS (http://blog.scottlogic.com/2016/01/20/restful-api-with-aspnet50.html) и как бы… все! Мы уже на 5-ой странице поисковой выдачи…
Подскажите, как вам удалось запустить hello-world веб-сервер.
yara_73
ок, смотрите, я делаю проект через yo, потом dnu restore, dnx web, делали ли вы рестор?
robert_ayrapetyan
Куча ошибок при restore (конфликты версий). Но главное это:
The DNX is being retired in favor of the new dotnet CLI command line tools. See:
http://dotnet.github.io/getting-started/
http://github.com/dotnet/cli
As a result, we're not accepting anymore changes to this project. Please file any new issues on http://github.com/dotnet/cli.
yara_73
Если вы не можете сделать рестор, значит вы и не запустите приложение. Ну и кстати попробуйте снести все и заново поставить с сайта MS, как я понял у вас RC1 приложение, вы обновили до RC2 и теперь не можете работать этим инструментарием, на сайте мс, вроде обновили инструкции, так как тулз dnx вышел на пенсию
robert_ayrapetyan
https://www.microsoft.com/net/core#ubuntu — именно отсюда и ставил все (шаг 1 выше). HTTP-сервер выкидывает ошибку, известный баг-стоппер, висит уже 3 месяца на гитхабе, выше ссылка.
Razaz
В баге написано — поправят к RTM. В чем проблема? Это же опенсорс. Знаете как починить — форк, фикс, пулл реквест.
DmitrySikorsky
За последние много лет я сделал больше сотни сайтов на ASP.NET и продолжаю. Мне очень нравится эта платформа и среда разработки. Думаю, это дело вкуса и зависит от задачи. Для меня C# — лучший язык (хотя я работаю со многими, вроде Java и Objective C). Лично для меня появление кроссплатформенной ASP.NET — по-настоящему важное событие, которому я чрезвычайно рад.
yara_73
Как вам новые конфиги в json? Считаете вы их лучше, нежели то, что было до этого?
DmitrySikorsky
Я с новой версией ASP.NET Core с превью или ранней беты (уже не помню), успел привыкнуть. Если честно, мне не так важен формат этого файла. Каких-либо проблем или сложностей не вызывает.
Milording
Хабр достаточно репрезентативен и это очень хорошо видно по популярности ваших комментариев в этом топике.
robert_ayrapetyan
20 свидетелей секты воскрешения .NET на всем хабре, минусящих комменты, без ответов по теме, пациент мертв.
overtest
Вашу мысль я понял — пациент мертв, потому что он не ставится на Ubuntu. В общем-то, мне, как, уверен, и большинству другим разработчикам на этой платформе, не придет в голову ставить его на Ubuntu. Это делается для других целей, и, видимо, пока большой приоритет этой задаче не поставлен. Но, как я сказал, разработчиков под ASP.NET MVC это не сильно огорчает. Лично меня полностью устраивает среда разработки MS Visual Studio — пока не видел ничего лучше в плане удобства разработки, отладки и т.п. Фреймворком ASP.NET MVC тоже полностью доволен, как и MS SQL SERVER. Так что, у нас все хорошо и вы напрасно беспокоетесь.
robert_ayrapetyan
Как вы считаете, почему MS так активно пытается развить направление .NET Core?
overtest
Давайте дождемся, пока все устаканится. Уверен, что все баги исправят и все будет хорошо.
overtest
Но даже если вдруг они возьмут и не оправдают ожиданий, меня это сильно не огорчит, т.к. я не являюсь приверженцем какой-либо идеологии/технологии/языка, и перейти на что-то другое не станет проблемой. Даже будет интересно освоить что-то новое. Но пока продукты MS мне очень нравятся в плане удобства разработки и рынка труда.
szKarlen
кто сказал, что у фреймворка больше нет сообщества ?!
ASP.NET Core — тот же MVC, только в профиль. основная работа ведется по кросплатформенному запуску веб-приложений, т.к. предыдущие версии (т.е. pipeline обработки запросов) сильно были завязаны на инфраструктуру IIS.
также поступает большое кол-во pull-реквестов от сообщества. чего только стоит патч увеличивающий производительность до более 1 млн. запросов в секунду.
MVC был создан под влиянием Ruby on Rails. Core — ориентирован на быстрое развертывание а-ля node.js.
ах да, забыл самое главное: ASP.NET востребован в Ынтерпрайзе, где много капиталовложений.
ZOXEXIVO
Издеваешься чтоли? У нас в Госсекторе полно ASP.NET MVC, не говоря уже о мелких конторах.
Фреймворк один из самых удобных и лучших и об этом не стоит трындеть на хабре, как о всяких Go, Python.
Есть один инструмент, который решает весь спектр задач, а не придумывает каждый год новый язык и платформу, т.к предыдущая чем-то не устраивала.
robert_ayrapetyan
Не переживай, все это будет снесено в ближайшие годы в рамках программы «импортозамещения».
.NET не плох (кто говорит что он плох то, а? дело вкуса), просто его дни сочтены, .NET Core опоздал сильно, не взлетит оно, лично пощупайте качество поделки, называемой RC2 (на отличной от win платформе)
ZOXEXIVO
Импортозамещать будут то, за что платят деньги, а тут все бесплатно и еще с открытыми исходниками.
Вы, видимо, не видите масштабов и внутренней кухни, поэтому так легко бросаетесь подобными словами.
RC1 запустилась на Ubuntu без проблем.
robert_ayrapetyan
Подскажи ссылку на инструкцию по установке и запуску простого веб-приложения (веб-сервер hello-world) на последних версиях .Net Core под Ubuntu 14? Заранее оговорюсь — недели полторы назад я проверял весь топ ссылок из гугла, ни одна не оказалась рабочей (все из-за жуткого бардака с совместимостью даже между минорными версиями).
Razaz
1. RC2 релизнулся 6 дней назад.
2. CLI, с которым связаны баги — в Preview.
Могу только посоветовать https://www.microsoft.com/net/core#ubuntu.
DmitrySikorsky
Project.json, кстати, никуда не делся. А изменения это нормально для развивающегося продукта.
masterL
Все же я, например, ожидал, что после RC 1 будет только багфикс и улучшение производительности и прочие стабилизации кодовой базы, не затрагивающая публичных интерфейсов приложения. А с такими глобальными изменениями приходят мысли, что с названием RC 1 немного поторопились и разработка в самом разгаре.
DmitrySikorsky
Согласен, что, пожалуй, с RC1 погорячились. Я тоже не ожидал, что много часов моей работы в итоге пропадет, т. к. все так круто изменилось. Но все-таки понять, что реализация не оптимальная и внести изменения на раннем этапе это лучше, чем просто развивать компромиссный вариант.
kanekt
>>убрали project.json и опять вернулись к старым файлам проектов csproj
в чего вы это взяли? Все осталось как есть.
Taritsyn
На InfoQ.com есть статья об этом — «.NET Core Plans to Drop project.json».
Razaz
1. Для начала вы бы послушали причины этого решения.
2. csproj будет аналогом project.json. В нем не будет явных инклюдов файлов.
FMA
В дополнение к этому есть статья blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json