Комментарии 71
Просто отлично! Особенно evaluate expression порадовал. Сколько раз приходилось писать маленькую консольную программку, чтобы нагенерировать каких-нибудь данных… Не создавать же каждый раз Text Template…
Вот только одно расстраивает — отсутствие возможности подключать свои библиотеки в источники резолва. То есть когда я пишу какой-нибудь var g = Graphics.FromImage(...), решарпер тут же предлагает подключить WindowsForms.dll и заюзать его, но вот стоит написать using(var client = new HttpClient()), то всё. А ведь System.Net.Http не менее важный неймспейс… Почему бы не дать пользователю возможость добавить свои dll для поиска? Неужели это так сильно на производительности сыграет или просто не было такой мысли?
Вот только одно расстраивает — отсутствие возможности подключать свои библиотеки в источники резолва. То есть когда я пишу какой-нибудь var g = Graphics.FromImage(...), решарпер тут же предлагает подключить WindowsForms.dll и заюзать его, но вот стоит написать using(var client = new HttpClient()), то всё. А ведь System.Net.Http не менее важный неймспейс… Почему бы не дать пользователю возможость добавить свои dll для поиска? Неужели это так сильно на производительности сыграет или просто не было такой мысли?
Вместо маленьких консольных программок хорошо подходит linqpad. А платная версия сама находит в GACе сборки по используемым классам и предлагает их заюзать.
Я постараюсь привести сюда автора и исполнителя этой фичи ControlFlow, который хоть сейчас и предается разврату где-то в Средиземноморье, но, надеюсь, сможет ответить на ваш вопрос.
Я так понимаю, что второй абзац не про «Evaluate expression» (он поддерживает исполнение кода только из BCL), а про import type popup. Дело в том, что типы из сборки System.Drawing.dll находятся решарпером не потому, что мы его куда-то захардкодили сборку или что-то подобное, а потому что оно попало к нам в кэш бинарных сборок и попробовать поискать в ней тип для нас — очень простая операция. Другое дело — как сборки попадают в этот кэш. Обычно туда попадает какой-то миниальный сабсет сборок BCL + все бинарные сборки всех референсов всех проектов солюшена. Если сборку System.Net.Http.dll референсит какой-нибудь соседний проект в солюшене, то import popup должен его вам предложить (иначе это баг).
Загружать в этот кэш все, что предлагает Visual Studio в диалоге «Add reference...» — не разумно, поэтому импорт типов и не работает по всем сборкам машины. У нас есть идеи как можно сделать такой импорт типов из всех сборок SDK текущей машины, возможно это будет продолжением новой фичи «Find type on nuget.org» (то есть поиск будет только по требованию, а не импорт-попапом). На данный момент, к сожалению, простого решения этой проблемы в ReSharper не существует.
Загружать в этот кэш все, что предлагает Visual Studio в диалоге «Add reference...» — не разумно, поэтому импорт типов и не работает по всем сборкам машины. У нас есть идеи как можно сделать такой импорт типов из всех сборок SDK текущей машины, возможно это будет продолжением новой фичи «Find type on nuget.org» (то есть поиск будет только по требованию, а не импорт-попапом). На данный момент, к сожалению, простого решения этой проблемы в ReSharper не существует.
Да, если в другом солюшене есть — действительно резолвит, спасибо за инфу.
Конечно, никто не предлагает делать кэш из полуторагигового фреймворка. Я просто думал, что можно кроме поиска по кэшу который есть сейчасть добавить возможность пользователю выбрать какие-то референсы, которые он часто использует (AccountManagment, Http, ...), то есть принудительно закэшировать десяток сборок сверху. Лично мне этой фичи и некоторым моим коллегам (которых я смог подбить на решарпер :) ) не хватает, особенно при работе с Sharepoint, потому там куча сборок, которые нужно референсить, но которые никогда в этот кэш не попадут. Не знаю, насколько фича сложна в имплементации, потому как я часто читаю Эрика, а у него любимая присказка — «вы представляете, НАСКОЛЬКО это сложно сделать» для нужных, но сложных фич и «если это так просто — напишите свою либу и пользуйтесь, не морочтье нам мозги» для простых. Поэтому я просто озвучиваю мнение независимой стороны. Ну а вы, как эксперты, сами регите, что с этим фидбеком делать — заводить фичреквест в джире или забить.
Загружать в этот кэш все, что предлагает Visual Studio в диалоге «Add reference...» — не разумно, поэтому импорт типов и не работает по всем сборкам машины.
Конечно, никто не предлагает делать кэш из полуторагигового фреймворка. Я просто думал, что можно кроме поиска по кэшу который есть сейчасть добавить возможность пользователю выбрать какие-то референсы, которые он часто использует (AccountManagment, Http, ...), то есть принудительно закэшировать десяток сборок сверху. Лично мне этой фичи и некоторым моим коллегам (которых я смог подбить на решарпер :) ) не хватает, особенно при работе с Sharepoint, потому там куча сборок, которые нужно референсить, но которые никогда в этот кэш не попадут. Не знаю, насколько фича сложна в имплементации, потому как я часто читаю Эрика, а у него любимая присказка — «вы представляете, НАСКОЛЬКО это сложно сделать» для нужных, но сложных фич и «если это так просто — напишите свою либу и пользуйтесь, не морочтье нам мозги» для простых. Поэтому я просто озвучиваю мнение независимой стороны. Ну а вы, как эксперты, сами регите, что с этим фидбеком делать — заводить фичреквест в джире или забить.
Ваши продукты очень хороши. Отдельно благодарю за студенческую лицензию.
ReSharper C++
А оно уже перестало тормозить, как не знаю что? Нажимаю Ctr+B (перейти к определению) и где-то секунды три оно рожает. В лучшем случае. И это на Core i7.
И так последние вижуалки не очень быстрые, а в купе с этим экстеншоном просто какой адовый песец. До сих пор приходится сидеть на 2008 студии.
А оно уже перестало тормозить, как не знаю что? Нажимаю Ctr+B (перейти к определению) и где-то секунды три оно рожает. В лучшем случае. И это на Core i7.
И так последние вижуалки не очень быстрые, а в купе с этим экстеншоном просто какой адовый песец. До сих пор приходится сидеть на 2008 студии.
Увы, мы не знаем, перестало ли оно тормозить у вас на вашей машине, на ваших проектах и в вашем окружении. Вам стоит попробовать, это лучший способ найти ответ на ваш вопрос.
Мы на перформанс, конечно, смотрим, что возможно фиксим и фиксить будем дальше. Мы допускаем, что могут быть серьезные тормоза на очень больших проектах с очень сложным кодом. В общем случае, однако, нам хочется думать, что серьезных тормозов быть не должно. Если они есть, то нам может потребоваться ваша помощь, поскольку в противном случае мы не узнаем о проблеме, а значит, скорее всего, не решим её. Имеет смысл выполнить такие действия:
1. Убедиться в соблюдении системных требований (указаны по ссылке со страницы Download).
2. Отключить в студии все плагины и расширения, кроме решарпера. Оценить обстановку.
3. Если п.2 не помогает, выбрать пункт ReSharper > Help > Profile Visual Studio и выполнить тормозящие операции под профилятором. Отправить снепшот нам в JetBrains (и снятие, и отправка делаются из одного окна, анонимизированная информация о системе собирается автоматически — т.е. процесс максимально упрощен)
4. Подождать некоторое время, пока мы ломаем голову над тем, что видим в снепшоте, и вносим исправления к следующему релизу
5. Скачать следующий релиз, поставить, попробовать.
6. В случае неудачи повторить.
Такие дела. Я надеюсь, вы поставите, попробуете, и все у вас взлетит с минимальным ущербом для отзывчивости студии. Ну а если нет, давайте сотрудничать: есть надежда, что в результате всем будет легче жить.
Мы на перформанс, конечно, смотрим, что возможно фиксим и фиксить будем дальше. Мы допускаем, что могут быть серьезные тормоза на очень больших проектах с очень сложным кодом. В общем случае, однако, нам хочется думать, что серьезных тормозов быть не должно. Если они есть, то нам может потребоваться ваша помощь, поскольку в противном случае мы не узнаем о проблеме, а значит, скорее всего, не решим её. Имеет смысл выполнить такие действия:
1. Убедиться в соблюдении системных требований (указаны по ссылке со страницы Download).
2. Отключить в студии все плагины и расширения, кроме решарпера. Оценить обстановку.
3. Если п.2 не помогает, выбрать пункт ReSharper > Help > Profile Visual Studio и выполнить тормозящие операции под профилятором. Отправить снепшот нам в JetBrains (и снятие, и отправка делаются из одного окна, анонимизированная информация о системе собирается автоматически — т.е. процесс максимально упрощен)
4. Подождать некоторое время, пока мы ломаем голову над тем, что видим в снепшоте, и вносим исправления к следующему релизу
5. Скачать следующий релиз, поставить, попробовать.
6. В случае неудачи повторить.
Такие дела. Я надеюсь, вы поставите, попробуете, и все у вас взлетит с минимальным ущербом для отзывчивости студии. Ну а если нет, давайте сотрудничать: есть надежда, что в результате всем будет легче жить.
Попробовал, действительно, стало заметно быстрее, чем когда я пробовал в прошлый раз. Спасибо!
Что-нибудь делать с несовместимостью с Productivity Power Tools планируется? По отдельности решарпер и тулзы работают нормально, а вместе ставят студию на колени, и ей становится невозможно пользоваться. Не знаю, кто виноват, но что-то же сделать можно, наверное?
В этих тулзах есть убер-фича — человеческое переключение табов: вертикальные табы, раскраска по проектам и т.п. Кроме всего прочего. Больше нормальные табы взять негде. А возвращение на ущербные стандартные табы вызывает ужасную боль. :(
Эта несовместимость — довольно распространённая проблема. На StackOverflow совет отключить PPT при тормозах решарпера собрал кучу плюсов.
В этих тулзах есть убер-фича — человеческое переключение табов: вертикальные табы, раскраска по проектам и т.п. Кроме всего прочего. Больше нормальные табы взять негде. А возвращение на ущербные стандартные табы вызывает ужасную боль. :(
Эта несовместимость — довольно распространённая проблема. На StackOverflow совет отключить PPT при тормозах решарпера собрал кучу плюсов.
ReSharper C++ просто великолепен, наблюдал со времен закрытой беты, думал что врятли и релиз на моих проектах сходу завертится, оказалось очень зря, шикарная работа!
Спасибо! Здорово, что так сразу завелось. Большие проекты-то?
Пробовал на двух проектах, по ~150k строк кода каждый, из больших библиотек — boost и Qt. В EAP были проблемы в основном с поддержкой используемых фич C++11 и хитрых темплейтов/макросов, включая используемые в библиотеках. Сейчас никаких ложных ошибок, по скорости — реально летает, даже не верится что столько фич решарпера теперь доступно в C++ :)
НЛО прилетело и опубликовало эту надпись здесь
Обоснуйте что ли.
НЛО прилетело и опубликовало эту надпись здесь
Tips on startup чего?
Посмотрел, и чем я должен был восхититься? Я пробовал многие IDE (в том числе VIM :D ), и больше студии мне ни одна не понравилась. Единственный минус студии — это то, что она обожает открывать xml-ки.
Хотя учитывая мощь студии ей можно это простить. А решарпер её очень приятно дополняет. Особенно радует решение подружиться с rosylin — до этого во всех источниках трубили, что у него фатальный недостаток и на него не перейдут. Однако на CLRium'е недавно было сказано, что CodeRush уже переписывается на rosylin, возможно, это как-то сподвигло.
Хотя учитывая мощь студии ей можно это простить. А решарпер её очень приятно дополняет. Особенно радует решение подружиться с rosylin — до этого во всех источниках трубили, что у него фатальный недостаток и на него не перейдут. Однако на CLRium'е недавно было сказано, что CodeRush уже переписывается на rosylin, возможно, это как-то сподвигло.
Отличная картинка )
Про Roslyn — мы на него по-прежнему не переходим, но коли у студии появился свой поп-ап для фиксов, то мы подумали, что надо сделать красиво и выводить их фиксы в своем попапе.
Про Roslyn — мы на него по-прежнему не переходим, но коли у студии появился свой поп-ап для фиксов, то мы подумали, что надо сделать красиво и выводить их фиксы в своем попапе.
… коли у студии появился свой поп-ап для фиксов, то мы подумали, что надо сделать красиво и выводить их фиксы в своем попапе.Интересная у вас логика.
Мы вообще творческие граждане. А что именно вам понравилось в логике?
Появился стандартный попап -> надо скопировать данные из него в свой, кастомный, а не копировать свои данные в стандартный. Впрочем, такая модель поведения вполне стандартна для R#.
С позиции оценочной можно сказать, что этот новый стандартный попап студии цельнослизан с нестандартного, неконвенционального и ужасного решарперного, а оригинал обычно лучше копии. Но здесь оценочность просто зашкаливает, конечно.
С технической позиции мне судить трудно, но подозреваю, что запихнуть студийные команды в решарперный попап могло быть сильно проще, чем разбираться с нестабильными и зачастую открывающимися взгляду случайно и неожиданно API 2015 студии. Собственно, в меру моего понимания именно этой особенностью во многих случаях объясняется поведение, которое, как вы говорите, вполне стандартно для R#.
С технической позиции мне судить трудно, но подозреваю, что запихнуть студийные команды в решарперный попап могло быть сильно проще, чем разбираться с нестабильными и зачастую открывающимися взгляду случайно и неожиданно API 2015 студии. Собственно, в меру моего понимания именно этой особенностью во многих случаях объясняется поведение, которое, как вы говорите, вполне стандартно для R#.
Ну хорошо, по причине нестабильности 2015 я вас обоих прощаю :) (/cc ControlFlow)
Но я считаю, что с таким подходом вы всегда будете в состоянии «догоняния» студии. Например, я был крайне разочарован, что вы писали поддержку TypeScript самостоятельно, а не взяли его компилятор. Из-за этого R# говорит глупости про абсолютно нормальный конструкции:
C# у вас тоже «с привкусом»:
Но я считаю, что с таким подходом вы всегда будете в состоянии «догоняния» студии. Например, я был крайне разочарован, что вы писали поддержку TypeScript самостоятельно, а не взяли его компилятор. Из-за этого R# говорит глупости про абсолютно нормальный конструкции:
declare function f<T>(a: T[], b: T[]): void;
f([], <number[]>[]);C# у вас тоже «с привкусом»:
class C {
unsafe ~C() { }
}Можно поподробнее про глупости и привкус? Хотелось бы разобраться, что именно не так.
А вы научите, как вот так взять успешный коммерческий продукт, выбросить устоявшиеся и проверенные временем семантические и сентаксические модели, забить на опыт, забить на то что ReSharper — это вообще-то проект на managed-коде… и делать поддержку TypeScript на TypeScript, используя TypeScript-компилятор.
Реимплементить часть компилятора — это парадигма всех IDE JetBrains (за исключением, наверное, только поддержки Kotlin). Это сложный выбор, который был сделан давно и показал себя с хорошей стороны. Да, мы часто страдаем от расхождений компиляторов и IDE, да нам нужны сильные программисты чтобы содержать много сложного компиляторо-подобного кода, но есть и множество плюсов: мы не зависим от релизных циклов компиляторов, мы можем писать поддержки любых языков на одном managed-языке (а не на языке компилятора) и шарить общую платформу и разные высокоуровневые модели, мы можем успешно поддерживать не последние версии языка (в компиляторах обычно нельзя включить диалект предыдущей версии или «отключить» breaking changes новой версии компилятора). Я буквально могу взять мелкую фичу из C#, удалить работу с типами и C#-специфичными выражениями и у меня получится практически рабочая фича для JavaScript. То есть я могу писать JS-поддержку практически в тех же терминах, что и в C# — и это просто замечательно, еще и применимо ко всем языкам.
p.s. Бага в TypeScript не воспроизвелась у меня в 9.1, а багу в C# я для вас починю обязательно.
Реимплементить часть компилятора — это парадигма всех IDE JetBrains (за исключением, наверное, только поддержки Kotlin). Это сложный выбор, который был сделан давно и показал себя с хорошей стороны. Да, мы часто страдаем от расхождений компиляторов и IDE, да нам нужны сильные программисты чтобы содержать много сложного компиляторо-подобного кода, но есть и множество плюсов: мы не зависим от релизных циклов компиляторов, мы можем писать поддержки любых языков на одном managed-языке (а не на языке компилятора) и шарить общую платформу и разные высокоуровневые модели, мы можем успешно поддерживать не последние версии языка (в компиляторах обычно нельзя включить диалект предыдущей версии или «отключить» breaking changes новой версии компилятора). Я буквально могу взять мелкую фичу из C#, удалить работу с типами и C#-специфичными выражениями и у меня получится практически рабочая фича для JavaScript. То есть я могу писать JS-поддержку практически в тех же терминах, что и в C# — и это просто замечательно, еще и применимо ко всем языкам.
p.s. Бага в TypeScript не воспроизвелась у меня в 9.1, а багу в C# я для вас починю обязательно.
Я всё это понимаю. Но простить не могу. Но конечный продукт от этого лучше не становится.
Запаковал вам тестовый проект. Заодно сунул туда ещё пару багов. VS 2013.4, R# 9.1.
Запаковал вам тестовый проект. Заодно сунул туда ещё пару багов. VS 2013.4, R# 9.1.
Баг в TS посмотрим, спасибо! Но скажу следующее:
как уже написал ControlFlow, мы пишем поддержки языков на языке IDE, потому что это
а) позволяет писать легко поддерживаемый и легко отлаживаемый код.
б) позволяет писать производительный код, прерываемый, асинхронный код
Компилятор TS написан на TS и слабо удовлетворяет обоим требованиям.
Во-первых, для запуска TS (точнее JS) нужно отдавать код в какой-нибудь V8 или IE, при этом теряется возможность отладки того, что происходит внутри.
Во-вторых, этот код непрерываемый «по-хорошему», только убийством фонового потока, В Решарпере все анализы прерываются на тайпинг любого символа в документе, вывод типов может запрашиваться 100-1000 раз на каждое изменение документа, и почти всегда это работает мгновенно, чего не скажешь о студии, которая вешает хайлайтинги в TS документе с задержкой около секунды.
В-третьих, когда мы имплементируем поддержку TS (как и других языков), мы руководствуемся спекой. А у компилятора TS мы выявили немалое кол-во расхождений со спекой языка (и репортили баги, конечно же). Было немало случаев, когда логику работы компилятора мы понять не смогли вообще (она не сходилась со спекой) и в разных примерах компилятор выдавал неадекватные результаты, например в отношении сравнения рекурсивных генерических типов. Даже чтение кода компилятора к прозрению не приводило.
В-четвертых, код компилятора очень нестабильный в плане API, подстраиваться под него и разбираться в изменениях, особенно, когда взаимодействие между R# и TS комилятором не строготипизированное — очень тяжелая задача, сложность которой, зависит уже не от нас.
Есть еще много пунктов, почему мы имплементим поддержку языков сами. Да, расхождения случаются, но мы стараемся их фиксить по мере поступления баг-репортов.
как уже написал ControlFlow, мы пишем поддержки языков на языке IDE, потому что это
а) позволяет писать легко поддерживаемый и легко отлаживаемый код.
б) позволяет писать производительный код, прерываемый, асинхронный код
Компилятор TS написан на TS и слабо удовлетворяет обоим требованиям.
Во-первых, для запуска TS (точнее JS) нужно отдавать код в какой-нибудь V8 или IE, при этом теряется возможность отладки того, что происходит внутри.
Во-вторых, этот код непрерываемый «по-хорошему», только убийством фонового потока, В Решарпере все анализы прерываются на тайпинг любого символа в документе, вывод типов может запрашиваться 100-1000 раз на каждое изменение документа, и почти всегда это работает мгновенно, чего не скажешь о студии, которая вешает хайлайтинги в TS документе с задержкой около секунды.
В-третьих, когда мы имплементируем поддержку TS (как и других языков), мы руководствуемся спекой. А у компилятора TS мы выявили немалое кол-во расхождений со спекой языка (и репортили баги, конечно же). Было немало случаев, когда логику работы компилятора мы понять не смогли вообще (она не сходилась со спекой) и в разных примерах компилятор выдавал неадекватные результаты, например в отношении сравнения рекурсивных генерических типов. Даже чтение кода компилятора к прозрению не приводило.
В-четвертых, код компилятора очень нестабильный в плане API, подстраиваться под него и разбираться в изменениях, особенно, когда взаимодействие между R# и TS комилятором не строготипизированное — очень тяжелая задача, сложность которой, зависит уже не от нас.
Есть еще много пунктов, почему мы имплементим поддержку языков сами. Да, расхождения случаются, но мы стараемся их фиксить по мере поступления баг-репортов.
Ооо, «производительный, прерываемый, асинхронный решарпер» это вообще отдельная история. Я вот работаю с проектом в 2 млн строк разнообразного кода (C#, JS, TS, разные web-вещи) и кучей библиотек. Извините, но производительностью и асинхронностью там мало пахнет. Приходится делать разные извраты, чтобы R# стал хоть сколько-то производительным (симлинкать bin папки, переносить весь репо в RAM). После билда висяк на пару минут — нормально, приходится отключать R# до билда. Редактирование */data/value в resx вешает всё на секунду — приходится отключать поддержку resx. Работа в TS тупо вертит пару ядер на 100% — опять же, Suspend (по крайней мере, в 9.0 так было). От подсветки решарпера укачивает, потому что она «мигает» постоянно. Не-родной IntelliSense подтормаживает (хотя я его отключил потому что некастомизируемый он). Раскрытие R# шаблона достаточно долгое. И ещё куча общих заметных подтормаживаний студии.
Однако, R# действительно быстрее и эффективнее, чем, скажем, CodeLens (правда, в 2015 обещали улучшить). Последние, зато, по-настоящему асинхронные — исполняются и хранят данные в отдельном процессе.
PS Вы уж простите что я вас в каждом топике про R# критикую :) Люблю очень, но некоторые моменты выводят из себя, вот и пишу :)
Однако, R# действительно быстрее и эффективнее, чем, скажем, CodeLens (правда, в 2015 обещали улучшить). Последние, зато, по-настоящему асинхронные — исполняются и хранят данные в отдельном процессе.
PS Вы уж простите что я вас в каждом топике про R# критикую :) Люблю очень, но некоторые моменты выводят из себя, вот и пишу :)
Вы лучше шлите снепшоты) будем разбираться. Решарпер конечно более нетороплив голой студии. Но и кол-во работы, которую он выполняет (анализы, подсветки, доступность экшенов и т.д.) раз в 100 больше, чем в студии. Если ту же функциональность попробовать поднять на коде комплилятора, то все умрет на проектах в 100 раз меньших, чем у вас.
НЛО прилетело и опубликовало эту надпись здесь
У нового «стандартного» меню (который еще не зарелизен и есть только в VS2015) нет и половины функционала нашей менюшки, нет встроенного поиска, другой стандартный хоткей, другая модель сортировки и группировки, его API до сих пор переделывали в последних CTP, студийная лампочка показывается в другом margin'е редактора (в который нам нетривиально добросить свои другие индикаторы, типа юнит-тестов, рекурсии, имплементации интерфейсов) и так далее.
Интересная у вас логика!
Интересная у вас логика!
CodeRush уже переписывается на rosylin
CodeRush объявили о решении переписаться на Roslyn ровно год назад, и с тех пор тишина. JetBrains успела выпустить за это время 2 огромных релиза.
Переписывать под Roslyn это не тривиальная задача. В проекте над которым сам работал, OzCode, мы решили переписать наш семантический анализ под Roslyn (вместо NRefactory), для того что бы поддержать новые фичи C# 6 — это было очень не простое решение. Работали над этим и Июня прошлого года, и только неделю назад вышла бета v2 OzCode-а. Можно почитать о принятие решения тут.
В случае ReSharper-а — у них узне давным давно есть свой «Roslyn», переписывать продукт размера R# это суицид, и с технической точки зрения и с точки зрения бизнеса: на это бы ушло как минимум года 2 (даже если бы модели работы R# и Roslyn совпадали, а они разные), и результат был бы никаким: Roslyn умеет понимать только C# и VB, а R# поддерживает и другие языки.
у них узне давным давно есть свой «Roslyn»Это вы про Nitra? Её не допилили же ещё, только сейчас пилится генерилка плагинов к R#.
Нет, про сам ReSharper.
ReSharper — это и есть «Roslyn», который случился на почти 10 лет раньше, изначально на managed коде, изначально с поддержкой нескольких языков (включая не CLR-языки). Единственные концептуальные отличия — у нас просто нет бэкендов (хотя можно было бы сделать) + в отличие от традиционных компиляторов мы заточены под постоянные изменения текста/AST (инкрементальность во все поля) и работу с незаконченным кодом. Все что сейчас толкает Roslyn — синтаксические деревья, семантические модели, движки dataflow-анализов, документные и проектные модели — были у нас реализованы когда Roslyn'а и в планах не было.
Но люди почему-то все равно уверены, что 10 лет технических инвестиций в это все надо просто выкинуть, а тонны кода анализов и фиксов C#/VB переписать на другое API, несовместимое с нашим привычным и используемым во всех других языках. Эх :)
ReSharper — это и есть «Roslyn», который случился на почти 10 лет раньше, изначально на managed коде, изначально с поддержкой нескольких языков (включая не CLR-языки). Единственные концептуальные отличия — у нас просто нет бэкендов (хотя можно было бы сделать) + в отличие от традиционных компиляторов мы заточены под постоянные изменения текста/AST (инкрементальность во все поля) и работу с незаконченным кодом. Все что сейчас толкает Roslyn — синтаксические деревья, семантические модели, движки dataflow-анализов, документные и проектные модели — были у нас реализованы когда Roslyn'а и в планах не было.
Но люди почему-то все равно уверены, что 10 лет технических инвестиций в это все надо просто выкинуть, а тонны кода анализов и фиксов C#/VB переписать на другое API, несовместимое с нашим привычным и используемым во всех других языках. Эх :)
Я просто говорю, недавно общался с представителями CodeRush, и они клялись и божились, что уже скоро. Конечно, может быть «это всё маркетинг», но они обещали релиз в ближайшее время. Просто мне казалось, что Rosylin больше использует инфы компилятора и меньше сам что-то анализирует, за счёт чего достигается повышение производительности и потребления памяти. Сейчас же, после ответа товарищей gorohoroh и ControlFlow я уже в этом не уверен.
У меня начиная с 9 версии появилась проблема, при включении dotTrace и всего остального помимо Resharper — студия начинает лагать при переключении вкладок. Если включен только решарпер вкладка переключается почти мгновенно, если включено все — переключение занимает минимум 1 секунду, иногда несколько секунд.
Интересно. А можете воспроизвести проблему под профилятором и заслать нам снепшот? В соседнем комментарии написано, как это можно сделать.
Спасибо!
Спасибо!
Вот этот реквест, кажется, связан с вашей проблемой. Если на 9.1 воспроизведется и снимите снепшот, пожалуйста, отпишитесь в комментариях к нему.
Есть ли в ReSharper возможность такого форматирования?:
habrastorage.org/files/bb9/cd5/ac2/bb9cd5ac20d74545bcc04d1631d3b098.png
habrastorage.org/files/bb9/cd5/ac2/bb9cd5ac20d74545bcc04d1631d3b098.png
Можете вылоижть этот кусок кода как текст? Я проверю
Коллеги сообщают, что нет, табличное форматирование не поддерживается.
Есть ли в планах на будущее такой функционал?
На данный момент в планах его нет, хотя когда-то его просили.
Мир жесток :(
Решил попробовать dotTrace. С сайта скачалась прога которая должна скачивать сам dotTrace. Это крайне неудобно мне пришлось добавлять эту тулзу в список разрешенных прог в фаерволе. В итоге вместо того что мне нужно скачался Resharper Ultimate хотя это не то, что было мне нужно, в итоге забил… а уровень раздражения вообще сложно передать.
Если веб-инсталлятор доттрейса вам не подходит, то инсталлятор ReSharper Ultimate — это как раз то, что нужно: он содержит все, что необходимо для установки всех продуктов, которые покрываются лицензией ReSharper Ultimate (ReSharper, ReSharper C++, dotTrace, dotMemory, dotCover, dotPeek). Перед установкой указываете, что именно из всего этого добра вам нужно установить, и поехали.
Вот хронология событий:
prntscr.com/6t9p2g
prntscr.com/6t9ou0
prntscr.com/6t9pad
prntscr.com/6t9pko — на лицо какой то баг, так что зря минусуете
Пустые окна, что куда установилось я так и не нашел. После чего потратил несколько минут и нашел таки прямую ссылку на ResharperUltimate ну думаю попробую рашарпер, скачал установил, захожу в меню About и вижу следующее:
prntscr.com/6t9wed
Что же будет дальше? :) уже страшно.
prntscr.com/6t9p2g
prntscr.com/6t9ou0
prntscr.com/6t9pad
prntscr.com/6t9pko — на лицо какой то баг, так что зря минусуете
Пустые окна, что куда установилось я так и не нашел. После чего потратил несколько минут и нашел таки прямую ссылку на ResharperUltimate ну думаю попробую рашарпер, скачал установил, захожу в меню About и вижу следующее:
prntscr.com/6t9wed
Что же будет дальше? :) уже страшно.
Нда, тут что-то определенно не так. Давайте завтра поговорю с Q&A, и если проблемы неизвестные, попытаемся воспроизвести.
Прошу прощения: так себе установка получилась.
Прошу прощения: так себе установка получилась.
Можно вас попросить выдать нам логи инсталлятора? Файлы вида InstallerLogNNN в папке %UserProfile%\AppData\Local\JetBrains\Shared\v02
Можно создать реквест, можно написать в саппорт, либо здесь выдать ссылку для скачивания логов: как удобно.
Спасибо!
Можно создать реквест, можно написать в саппорт, либо здесь выдать ссылку для скачивания логов: как удобно.
Спасибо!
Надеюсь поможет 1drv.ms/1EAMhFt
И я надеюсь. Спасибо!
Падает не исталятор, а уже сам решарпер.
Предлагаю переместиться в ишью для дальнейшего решения проблемы.
Предлагаю переместиться в ишью для дальнейшего решения проблемы.
Установил Resharper С++. Солюшен из >75 проектов распарсился минут за 5-10. В целом, все работает довольно быстро. Функционал богаче, чем у Visual Assist'а. Но студия у меня сегодня 1 раз уже упала от нехватки памяти :( 32-битному процессу не хватило 4 Гб памяти.
4ГБ — это, увы, нижняя планка нынешних системных требований семейства ReSharper Ultimate, которые, честно говоря, слегка устарели.
А то, что несмотря на это оно работает довольно быстро — это хорошо и удачно.
А то, что несмотря на это оно работает довольно быстро — это хорошо и удачно.
Было бы просто замечательно, если бы вы смогли снять снепшотик managed-хипа разожравшегося devenv.exe триалочкой dotMemory, чтобы у нас было представление что там распухло в памяти так :(
промахнулся комментом
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Доступно свежее обновление ReSharper Ultimate