UPD: вариантов решений вообще много, вплоть до переключения Hangfire-серверов на новый экземпляр базы данных Hangfire при апдейте системы, не прекращая поддержку старого, что логично.
Возможный workaround: для повторяемых/отложенных задач хранить их id, далее при обновлении системы заменять задачи в БД новой версией.
Безусловно, проблема есть, но она решаема в разумные сроки.
Например, выполнение задач по-расписанию (загрузка новых данных, тяжелые скрипты по ночам). Или перенос с клиента в отдельный какой-либо ресурсоемкой задачи.
Безальтернативно объявлять наследование злом — конечно, неправильно. Но и обратная «абсолютная» точка зрения ничем не лучше. К примеру, еще во всем известной книге GoF по паттернам проектирования было аргументировано правило «предпочитайте композицию наследованию»: en.wikipedia.org/wiki/Composition_over_inheritance
Думаю, что этот спор ни к чему не приведет, все останутся при своем мнении. У меня скорость работы с текстом в студии или в SSMS + SQL Prompt не ниже, чем в Notepad++, которым я тоже активно пользуюсь. Но вы же не поверите? =) И да, я считаю, что у разработчика должен быть мощный компьютер.
нет, на домашнем компе 16 в свободном доступе и еще 16 отведено под RAM-диск. Захотел отвлечься — сворачиваю студию, запускаю вдобавок Lightroom/Photoshop, хоть что угодно. Аптаймом не меряюсь, у меня перезагрузка никак не связана с интенсивностью или продолжительностью работы.
Иногда держу по 5-6 студий с решарпером открытыми, как дома, так и на работе (+ та же самая куча дополнительных программ). Перезагружаю компьютер раз в пару недель. Ничего не тормозит, не залипает, как так?
Время покажет. Надеюсь, что упростится поиск информации по классам с одинаковым в MVC5 и MVC6 названием, но кардинально разным поведением и содержимым. Так как сейчас даже на StackOverflow люди часто не заморачиваются и лепят один тэг [asp.net-mvc], никто за этим особо не следит.
ссылка на DevGuide встречается по тексту статьи раз 5, я просто не стал (или забыл) указывать ее явно. Для общения с разработчиками удобнее использовать оф. форумы JetBrains Developer Community. Спасибо за замечание, дополню текст статьи.
Мне понравилась эта вводная статья по анализаторам, просто и понятно все расписано.
Насколько я знаю, JetBrains не собирались переходить на Roslyn по ряду технических и экономических причин, так что в ближайшие годы ReSharper API вряд ли потеряет актуальность.
Безусловно, проблема есть, но она решаема в разумные сроки.
Насколько я знаю, JetBrains не собирались переходить на Roslyn по ряду технических и экономических причин, так что в ближайшие годы ReSharper API вряд ли потеряет актуальность.