Comments 121
Среди альтернатив на macOS по разработке на .NET (Core) — лучшее, по моему субъективному мнению.
Когда-то пробовал райдер EAP. Потом когда причесали баги vscode с sln, csproj тестами, отладкой и выпустили удобный dotnet cli для работы солюшином перестал следить за обновлениями райдера, хотя под виндой пользуюсь с студей решарпером и являсь сторонником продукта. Под маком vs code крайне удобен — ux мне нравиться больше чем R# студии и то, что было на тот момент, когда пробовал в райдере.
Есть места конечно где приходиться больше времени терять на набор текста, подключение референсов, нугетов, сборку.
Но это компенсируеться огромным количеством готовых рабочих плагинок опен сорсных под различные технологии с подсветкой code snippets — go, ts, js, jsx, tsx и т.д. Не уверен есть ли это все в райдере или для работы над фронт ендом надо ставить web storm например.
Реально в vscode не хватает декомпиляции в реальном времени — вот тут уже очень ощутимый
недостаток, что приходиться тянуть с гитхаба код и работать со сторонним кодом только так.
История про проблемы с отладкой (неожиданное изменение лицензирования пакета от МС) оставила неравнодушной!
А что не так? МС поступила как-то несправедливо и постыдно по отношению к Jet Brains, которые собирались использовать открытый дебагер МС в своем коммерческом продукте?
Мне удобно писать в Rider'е, так производительнее для меня, т.к. Rider это не только редактор и плагины для подсветки, это куча классных инспекций из ReSharper, которые я использую каждый день и не собираюсь отказываться. Вам удобно делать свои .NET Core продукты в Visual Studio Code — Ваше право. Почему в итоге мы с Вами не можем двигать продукт (не важно коммерческий он для них или нет, они его двигают всеми силами) МС .NET Core удобным для нас с Вами способом?
Под линуксом сейчас особо ничего кроме GTK# и нет. Ну и работающего поверх него eto.Forms. Поддержка GTK# в Xamarin.Forms пока в процессе изготовления. Авалония в альфе. На макоси Cocoa, но для неё всё равно надо запускать Xcode, емнип. Так что в условиях отсутствия имеющихся средств на райдер в этом плане рассчитывать несколько странно. Мы у себя в авалонии для райдера плагин, конечно, сделаем, но когда этот светлый момент настанет, предсказывать не берусь.
Проблему с отладкой в асинхронном коде мы уже тестируем, опубликуем, видимо, в составе в 2017.1.1.
Да, собственно, из-за проблем с отладкой асинхронного кода я вернулся обратно на студию.
Rider/Resharper — изумительное средство для написания и рефакторинга кода, но вот отладка кода не является его сильной стороной. В частности:
Невозможна полноценная отладка асинхронного кода, как уже замечено выше. Будет исправлено — хорошо.
Expression Evaluation очень неудобен. Вместо настраиваемого отображения и кастомных визуализаторов показывает кишки объектов.
- Нет возможности остановки при выбросе исключения, а не при его перехвате.
Ну и до кучи тормоза Rider-а на больших файлах, на которых голая студия летает плюс невозможность одновременной работы с C# и C++.
Субъективно — производительность отличная. В отличие от студии+решарпера, работа с крупным проектом в rider не раздражает. Тормоза изредка случаются, но по сравнению с постоянно зависающей и вылетающей 3 раза за день студией — прекрасно. Это личный опыт, YMMV.
Мне кажется, студия вылетает из-за решарпера.
Сколько ни пользовался ванильной студией — не припомню вылетов в последнее время.
После выхода 2017-ой студии C# разработчики разделились на два лагеря. У одних она каждые 15минут/полчаса/час/день/вставить_нужное зависает/падает/выдаёт_ошибку, а у других такая же нога и не болит.
Ну так давайте искать причину. Я высказал предположение о наличии решарпера или других плагинов
А вдруг это заговор JetBrains и они специально крашат студию, чтобы люди переходили на Rider?
Причина одна. Новый SDK и интеграция оного со студией ну ооочень сырые. Пока пользуешься только классическими проектами — всё в целом нормально. Пока пользуешься только .NET Core + ASP.NET Core — всё в целом нормально. Стоит сделать шаг в сторону, где это хоть как-то перемешивается, и в этот прекрасный момент, как говорил один персонаж, сама собой откапывается зарытая собака и начинает тебя грызть.
Плюс они сейчас перешли на новую систему проектов. Которая поддерживает мультитаргетинг, асинхронна и всё такое. Но вот незадача — старое (синхронное) апи, которым пользуются все расширения, теперь начинает тормозить и виснуть. Такая банальная вещь как обход дерева проектов и извлечение списка зависимостей теперь на достаточно большом солюшне занимают вместо 10-20мс 2-3 секунды. Это только то, с чем я столкнулся при разработке расширений.
Далее. Новый нугет. Поддержка транзитивных зависимостей, ссылки на библиотеки прямо в общем кэше. Только вот медленно это всё очень работает. Особенно если где-то вылезла ошибка. У меня рекорд был, когда это чудо 15 минут зависимости разрешить пыталось, притом что все пакеты уже скачаны и в кэше лежат.
Спасибо, теперь после взгляда со стороны разработчика расширений всё понятно.
Я бы к этому еще добавил то, что из-за маленькой особенности студии в виде 32-битности эта конструкция бытро упирается в лимит по памяти. Голая студия в него вполне влезает, а вот решарпер (или другие крупные расширения) уже умещается плохо. Так что в в том, что виноваты плагины (фактом своего наличия), я не сомневаюсь, и на голой студии проблемы с нехваткой ресурсов, я уверен, не будет. Но только голая студия по сравнению с vs + r# или Rider — примерно как блокнот.
Но только голая студия по сравнению с vs + r# или Rider — примерно как блокнот.
Да нет, всё уже не настолько ужасно, особенно в VS2017.
Я пробовал недавно голую vs 2017 пол-дня, больше не хочу. Я знаю, что в студии много всякой фигни, она развивается, есть разные рефакторинги и все такое, но субъективно — "спасибо, нет". Хотя бы за медленный поиск текста по всему солюшену или ущербное средство запуска юнит-тестов. А если сравнивать с rider — так в студии даже текстовый редактор откровенно слабый и чекаут сделать невозможно без боли.
Кажется, в vs 2017 на эту тему что-то делали, но это актуально не везде. Видимо для этого нужна специальная поддержка в том числе со стороны плагина. Уверен, kekekeks сможет сказать точнее, как это работает и работает ли вообще.
Поддержу реквест. RIder вообще не понимает *.fsx сейчас.
Azure Functions — это сейчас моя основная деятельность, пришлось перейти обратно на VS.
В начале это связано с этим — https://youtrack.jetbrains.com/issue/RIDER-8429 (обещали сделать), т.к. без fsx вообще ничего не заработает.
Честно скажу, писать реквест на Azure Functions не буду, т.к. понимаю что это очень нишевая технология, которую даже VS плоховато поддерживает. А у Rider ещё много других проблем. Даже реквест, который Вы линканули, касающийся общей интеграции с Azure, как я понимаю, ещё не выполнен.
Написал там, напишу и здесь.
Azure Functions — это "serverless" скрипты, которые могут быть написаны на C#, F#, JS, PHP, Python и пр, поставлены на таймер (через cron expression), или на триггер (по http запросу, на событие в шине, на сообщение в очереди, на новые данные в сторадже и т.д.) и выполняющие какие-то действия.
Они интегрированы со всеми Azure технологиями, пайплайнами, бигдата хранилищами, api и пр.
Оплата за кол-во использований и за время работы, т.е. виртуалку можно не держать 24/7, а платить только за скорость кода :)
Очень хочу поддержку этой технологии в Rider, потому что Rider — хорош, но работать с enterprise технологиями пока не получается.
Не триальная, не на 30 дней, а полностью бесплатная (пусть и с урезанным функционалом)?
А то не понятно вот это: «Rider теперь можно не только загрузить, но и купить.»
Если бесплатной версии нет, то получается, что смысл фразы: «Rider теперь можно не только КУПИТЬ, но и КУПИТЬ.» Какая-то маркетинговая лажа.
Если можно скачать бесплатную версию, тогда всё логично. Уточните пожалуйста.
Формулировка, которую вы называете маркетинговой лажей, означает, как верно расшифровали ниже, что мы открыли продажи, тогда как в предшествующее предрелизье их по понятным причинам не было, была только возможность загрузить EAP-билд.
Просто в последнее время очень можно стало повышать цены «по просьбам трудящихся» или «мы отменили безлимит, потому что он больше никому не нужен и вам теперь будет ещё лучше чем прежде» и т.д.
Будем ждать бесплатную версию и продолжать пользоваться МоноДевелоп. Если появится бесплатная версия, обязательно будем пробовать.
Спасибо.
К JB не имею отношения, но вы осознаёте, что кушая кактус монодевелопа за год теряете существенно больше стоимости подписки на райдер?
Хотя я и не исключаю, что для кого-то монодевелопа недостаточно. Пусть покупают, ничего не имею против.
Xamarin.Android неофициально завели. Ну как неофициально, линуксовые бинарники скачиваются с Xamarin-овского билд-сервера.
Даже с райдером работает.
Скорость загрузки однако весьма порадовала.
Если ваша проблема про это, то прокомментируйте реквест https://youtrack.jetbrains.com/issue/RIDER-6937
Могли бы вы попробовать поменять TargetFramework в Project Properties на 4.6.1, чтобы уже точно удостовериться, что проблема в этом. Я не могу на чистой машине воспроизвести эту вариацию проблемы (с ".Net framework с 4.0 по 4.6.1 «через» VS installer").
Кроме того, кажется, что если все таргет-фреймворки установлены, то студия не предлагает мне сменить 4.5 на более подходящую.
Но проблему, которую удалось воспроизвести, про отсутствующий 4.5 будем фиксить конечно.
Для них только гуй надо ещё сделать суметь. На Swing/AWT.
Кросс-платформенный профилятор у нас сейчас не готов, а у команды dotTrace есть дела, которые они хотят сделать до того, как его доготовят. Поэтому каких-то подвижек по части профиляции не под Windows я бы ожидал не ранее, чем через год.
Пока что можно пользоваться связкой из perfcollect и hotspot
Тогда это было шуткой https://habrahabr.ru/post/218187/#comment_7462833
в VS2017 тесты видны и запускаются.
Райдер клевый, но дайте скорее нормальное апи для плагинов в том числе гуёвых :-) На студию можно гнать сколько угодно но у нее за спиной огромное апи и огромное количество плагинов. И да, на каком языке надо будет писать плагины? ;-)
исправил на C:\Program Files (x86)\…
Но проект все равно не собрался по этой причине. Ок, удалил .resx, заменив на embedded resources.
Теперь не собирается т.к. .resx используется в автосгенеренном файле миграции (code first, DbMigration..)
наверно нужно ждать осенний релиз…
p.s. верный способ диагностировать такие проблемы — попробовать собрать проект из консоли. Если из консоли работает, то и райдер должен =)
На stepic.org за решение задач по программированию. Ключи действуют короткое время.
Глупый вопрос, но интеграции с рослином нет никакой? Все эти анализаторы/кодогенераторы и прочее в райдере не заведутся by design?
Спасибо. Кстати, анализаторы — это неплохо, но в будущем необходимость в такой фиче для людей резко возрастет с реализацией этой issue, равно как и необходимость в довольно масштабных изменениях самой IDE.
Там вот дока залинкована.
Но вкратце это поддержка АОП на уровне языка. Чтобы можно было писать
// user written code
public partial class MyClass
{
public int Property { get; set; }
}
// tool generated code
public partial class MyClass : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
public supersede int Property
{
get { return superseded; }
set
{
if (superseded != value)
{
superseded = value;
var ev = this.PropertyChanged;
if (ev != null) ev(this, new PropertyChangedEventArgs(“Property”));
}
}
}
}Там много нюансов по сути работы (они описаны в основном по последней ссылке), но смысл примерно такой.
Кажется именно эта фича у нас заведется без проблем. Нужно только научиться звать компилятор в режиме кодогенерации в момент загрузки проекта и затягивать во все анализы решарпера сгенерированные файлы.
Мы так сейчас делаем, например, для Xamarin — вызываем специальные таски для генерации биндингов для andriod / ios и учитываем в анализах все сгенерированные файлы.
Просто я года 3 или 4 назад на дотнексте или clrium'е были выступления команд CodeRush и решарпера. Первые сказали "мы переписали все на рослин и снизили затраты памяти до 200МБ", а вторые "мы точно не будем переписывать, рослин не ок, в 32процессе нам тесно", из чего я сделал вывод, что поддержки рослина не будет вообще никакой. А тут прям приятные новости, спасибо.
JetBrains Rider 2017.1 — первый релиз новой кроссплатформенной .NET IDE