Полный список входящих в новый релиз ReSharper Ultimate обновлений таков: ReSharper 9.1, ReSharper C++ 1.0, dotMemory 4.3, dotTrace 6.1, dotCover 3.1 и dotPeek 1.4. Разберем наиболее заметные изменения в этих продуктах.
Помимо исправления более 700 разных проблем, ReSharper 9.1 вносит ряд существенных дополнений:
- Улучшенная поддержка Visual Studio 2015 и .NET 4.6. ReSharper 9.1 теперь показывает в своем контекстном меню не только собственные квик-фиксы и контекстные действия, но и исправления, которые предлагает Roslyn. Вы можете выбирать между ними и применять те, что вам по душе:
- Развитие поддержки C# 6. В частности, появилась поддержка интерполяции строк и оператора
nameof(). Чтобы упростить процесс миграции проектов на новую версию языка, ReSharper содержит квик-фиксы для трансформации кода в масштабе файла, проекта или целого солюшена.
- Что касается JavaScript и TypeScript, то мы добавили поддержку JSDoc, доделали TypeScript 1.4, поработали над TypeScript 1.5 и EcmaScript 6.
- Новое контекстное действие Evaluate expression позволяет посмотреть на результаты исполнения прямо в редакторе. По сути, речь идет о REPL в Visual Studio: можно изучать поведение стандартной библиотеки классов .NET, даже не запуская свое приложение. Поддерживается почти весь набор допустимых в C# выражений, в том числе LINQ и некоторые конструкции C# 6.
- Улучшения в автодополнении кода, в первую очередь новый механизм сортировки результатов по релевантности, призванный сделать так, чтобы самые подходящие варианты в списке автодополнения всегда были на первых местах.
- Обнаружение NuGet-пакетов, содержащих искомый тип. Если в вашем коде имеется указание на тип или пространство имен, которого нет ни в одной из доступных локально библиотек или пакетов, ReSharper предложит поискать этот тип или пространство имен в галерее пакетов NuGet. Все найденные пакеты будут вам показаны, и вы сможете выбрать из них тот, который вам нужен. Как водится, пункт поиска в NuGet доступен в меню, которое вызывается сочетанием клавиш Alt+Enter:
- Новый тип шаблонов кода Source Templates позволяет создавать шаблоны не в отдельном редакторе, а прямо в коде. Определяются они как методы расширения:
Другие инструменты в составе ReSharper Ultimate также претерпели разнообразные изменения:
- В dotCover 3.1 улучшена поддержка тестов MSTest и WinStore, а также исправлен ряд проблем с инструментарием командной строки.
- dotTrace 6.1 получил давно ожидаемую поддержку SQL-запросов в Timeline-профилировании: теперь значительно проще разобраться, сколько времени занял конкретный SQL-запрос и какой метод его запустил.
- И без того обширный набор способов визуализации результатов профилирования в dotMemory 4.3 пополнился круговой диаграммой доминаторов. Эта диаграмма помогает быстро понять, на какие объекты нужно обратить внимание в первую очередь и каким образом приложение потребляет память.
- Мы также выпустили первую версию нового фреймворка под названием dotMemory Unit — это механизм, с помощью которого можно писать юнит-тесты на потребление памяти. Больше информации об этом фреймворке можно найти в недавнем блог-посте (по-английски).
- dotPeek 1.4 теперь тоже поддерживает Visual Studio 2015 и C# 6.
Помимо вышеупомянутых обновлений в продуктах, ориентированных в первую очередь на .NET-разработчиков, мы выпустили первую версию ReSharper C++. Это отдельный продукт для разработчиков, которые пишут на C/C++ в Visual Studio. ReSharper C++ унаследовал большинство фич «основного» ReSharper’a, в том числе связанные с навигацией, шаблонами, генерацией и анализом кода. Подробнее о ReSharper C++ мы напишем чуть позже в отдельном посте.
Что касается лицензирования, мы предлагаем несколько вариантов:
- ReSharper 9.1 — бесплатное обновление для всех, у кого есть лицензия на 9.0, либо активная подписка.
- Лицензия ReSharper Ultimate включает в себя все вышеупомянутые продукты: ReSharper, ReSharper C++, dotTrace, dotCover и dotMemory. Больше информации о ReSharper Ultimate можно найти у нас на сайте.
- ReSharper C++ требует либо отдельной лицензии, либо лицензии ReSharper Ultimate.
- Если вам нужна помощь в покупке, можно связаться с нашим отделом продаж.
Комментарии (71)
AndrewNikolaevich
09.04.2015 17:47+6Ваши продукты очень хороши. Отдельно благодарю за студенческую лицензию.
SerJook
09.04.2015 18:01-7ReSharper C++
А оно уже перестало тормозить, как не знаю что? Нажимаю Ctr+B (перейти к определению) и где-то секунды три оно рожает. В лучшем случае. И это на Core i7.
И так последние вижуалки не очень быстрые, а в купе с этим экстеншоном просто какой адовый песец. До сих пор приходится сидеть на 2008 студии.gorohoroh
09.04.2015 22:52+5Увы, мы не знаем, перестало ли оно тормозить у вас на вашей машине, на ваших проектах и в вашем окружении. Вам стоит попробовать, это лучший способ найти ответ на ваш вопрос.
Мы на перформанс, конечно, смотрим, что возможно фиксим и фиксить будем дальше. Мы допускаем, что могут быть серьезные тормоза на очень больших проектах с очень сложным кодом. В общем случае, однако, нам хочется думать, что серьезных тормозов быть не должно. Если они есть, то нам может потребоваться ваша помощь, поскольку в противном случае мы не узнаем о проблеме, а значит, скорее всего, не решим её. Имеет смысл выполнить такие действия:
1. Убедиться в соблюдении системных требований (указаны по ссылке со страницы Download).
2. Отключить в студии все плагины и расширения, кроме решарпера. Оценить обстановку.
3. Если п.2 не помогает, выбрать пункт ReSharper > Help > Profile Visual Studio и выполнить тормозящие операции под профилятором. Отправить снепшот нам в JetBrains (и снятие, и отправка делаются из одного окна, анонимизированная информация о системе собирается автоматически — т.е. процесс максимально упрощен)
4. Подождать некоторое время, пока мы ломаем голову над тем, что видим в снепшоте, и вносим исправления к следующему релизу
5. Скачать следующий релиз, поставить, попробовать.
6. В случае неудачи повторить.
Такие дела. Я надеюсь, вы поставите, попробуете, и все у вас взлетит с минимальным ущербом для отзывчивости студии. Ну а если нет, давайте сотрудничать: есть надежда, что в результате всем будет легче жить.SerJook
09.04.2015 23:04+9Попробовал, действительно, стало заметно быстрее, чем когда я пробовал в прошлый раз. Спасибо!
Athari
10.04.2015 23:24Что-нибудь делать с несовместимостью с Productivity Power Tools планируется? По отдельности решарпер и тулзы работают нормально, а вместе ставят студию на колени, и ей становится невозможно пользоваться. Не знаю, кто виноват, но что-то же сделать можно, наверное?
В этих тулзах есть убер-фича — человеческое переключение табов: вертикальные табы, раскраска по проектам и т.п. Кроме всего прочего. Больше нормальные табы взять негде. А возвращение на ущербные стандартные табы вызывает ужасную боль. :(
Эта несовместимость — довольно распространённая проблема. На StackOverflow совет отключить PPT при тормозах решарпера собрал кучу плюсов.
Bronx
11.04.2015 08:15Попробуйте Tabs Studio. Платная, но у меня, как у tab junkie, удобства перевесили жабу.
DragonFire
11.04.2015 12:06Привет, поискал в нашем трекере и не нашел реквестов на такую проблему. Можете поподробнее описать, что там происходит? Возможно, снять снапшот…
Skara
09.04.2015 19:09ReSharper C++ просто великолепен, наблюдал со времен закрытой беты, думал что врятли и релиз на моих проектах сходу завертится, оказалось очень зря, шикарная работа!
gorohoroh
09.04.2015 22:23Спасибо! Здорово, что так сразу завелось. Большие проекты-то?
Skara
10.04.2015 03:38Пробовал на двух проектах, по ~150k строк кода каждый, из больших библиотек — boost и Qt. В EAP были проблемы в основном с поддержкой используемых фич C++11 и хитрых темплейтов/макросов, включая используемые в библиотеках. Сейчас никаких ложных ошибок, по скорости — реально летает, даже не верится что столько фич решарпера теперь доступно в C++ :)
gorohoroh
10.04.2015 13:22О, это хорошо. 150к не очень много, но уже очень радует, особенно по сравнению с нашим EAP-ным ограничением в 40к. Продолжаем наблюдение.
StrangerInRed
09.04.2015 21:29-10Мертвому припарки. Все равно VS это не CLion, и даже не далеко.
gorohoroh
09.04.2015 22:23+3Обоснуйте что ли.
StrangerInRed
09.04.2015 22:27-4Да, я собственно сознательно шел на этот харосуицид. Просто попробуйте и почитайте tips on startup.
gorohoroh
09.04.2015 22:53Tips on startup чего?
StrangerInRed
10.04.2015 09:21-2Да что-то сьело слово. Clion попробуйте (или AppCode). Idea-продукты вообще очень круты. И VS даже рядом не стояло.
Danov
10.04.2015 09:27+3Это у вас такой затянутый завёрнутый комплимент разработчику AppCode & ReSharper & IntelliJ IDEA…?
Или ваш удар летел в сторону MS?StrangerInRed
10.04.2015 09:37Двух зайцев одним выстрелом. А вообще, у меня не хватит слов, чтобы выразить JetBrains благодарность за их продукт. И особенно благодарность за опенсорс лицензии.
PsyHaSTe
09.04.2015 23:38+8Посмотрел, и чем я должен был восхититься? Я пробовал многие IDE (в том числе VIM :D ), и больше студии мне ни одна не понравилась. Единственный минус студии — это то, что она обожает открывать xml-ки.
Хотя учитывая мощь студии ей можно это простить. А решарпер её очень приятно дополняет. Особенно радует решение подружиться с rosylin — до этого во всех источниках трубили, что у него фатальный недостаток и на него не перейдут. Однако на CLRium'е недавно было сказано, что CodeRush уже переписывается на rosylin, возможно, это как-то сподвигло.gorohoroh
09.04.2015 23:51Отличная картинка )
Про Roslyn — мы на него по-прежнему не переходим, но коли у студии появился свой поп-ап для фиксов, то мы подумали, что надо сделать красиво и выводить их фиксы в своем попапе.
a553
10.04.2015 05:41+1… коли у студии появился свой поп-ап для фиксов, то мы подумали, что надо сделать красиво и выводить их фиксы в своем попапе.
Интересная у вас логика.gorohoroh
10.04.2015 13:42Мы вообще творческие граждане. А что именно вам понравилось в логике?
a553
10.04.2015 13:52Появился стандартный попап -> надо скопировать данные из него в свой, кастомный, а не копировать свои данные в стандартный. Впрочем, такая модель поведения вполне стандартна для R#.
gorohoroh
10.04.2015 14:01+4С позиции оценочной можно сказать, что этот новый стандартный попап студии цельнослизан с нестандартного, неконвенционального и ужасного решарперного, а оригинал обычно лучше копии. Но здесь оценочность просто зашкаливает, конечно.
С технической позиции мне судить трудно, но подозреваю, что запихнуть студийные команды в решарперный попап могло быть сильно проще, чем разбираться с нестабильными и зачастую открывающимися взгляду случайно и неожиданно API 2015 студии. Собственно, в меру моего понимания именно этой особенностью во многих случаях объясняется поведение, которое, как вы говорите, вполне стандартно для R#.a553
10.04.2015 14:23Ну хорошо, по причине нестабильности 2015 я вас обоих прощаю :) (/cc ControlFlow)
Но я считаю, что с таким подходом вы всегда будете в состоянии «догоняния» студии. Например, я был крайне разочарован, что вы писали поддержку TypeScript самостоятельно, а не взяли его компилятор. Из-за этого R# говорит глупости про абсолютно нормальный конструкции:
declare function f<T>(a: T[], b: T[]): void; f([], <number[]>[]);
C# у вас тоже «с привкусом»:class C { unsafe ~C() { } }gorohoroh
10.04.2015 17:34Можно поподробнее про глупости и привкус? Хотелось бы разобраться, что именно не так.
ControlFlow
10.04.2015 19:14+5А вы научите, как вот так взять успешный коммерческий продукт, выбросить устоявшиеся и проверенные временем семантические и сентаксические модели, забить на опыт, забить на то что ReSharper — это вообще-то проект на managed-коде… и делать поддержку TypeScript на TypeScript, используя TypeScript-компилятор.
Реимплементить часть компилятора — это парадигма всех IDE JetBrains (за исключением, наверное, только поддержки Kotlin). Это сложный выбор, который был сделан давно и показал себя с хорошей стороны. Да, мы часто страдаем от расхождений компиляторов и IDE, да нам нужны сильные программисты чтобы содержать много сложного компиляторо-подобного кода, но есть и множество плюсов: мы не зависим от релизных циклов компиляторов, мы можем писать поддержки любых языков на одном managed-языке (а не на языке компилятора) и шарить общую платформу и разные высокоуровневые модели, мы можем успешно поддерживать не последние версии языка (в компиляторах обычно нельзя включить диалект предыдущей версии или «отключить» breaking changes новой версии компилятора). Я буквально могу взять мелкую фичу из C#, удалить работу с типами и C#-специфичными выражениями и у меня получится практически рабочая фича для JavaScript. То есть я могу писать JS-поддержку практически в тех же терминах, что и в C# — и это просто замечательно, еще и применимо ко всем языкам.
p.s. Бага в TypeScript не воспроизвелась у меня в 9.1, а багу в C# я для вас починю обязательно.
nerzhul
15.04.2015 02:25+1Баг в TS посмотрим, спасибо! Но скажу следующее:
как уже написал ControlFlow, мы пишем поддержки языков на языке IDE, потому что это
а) позволяет писать легко поддерживаемый и легко отлаживаемый код.
б) позволяет писать производительный код, прерываемый, асинхронный код
Компилятор TS написан на TS и слабо удовлетворяет обоим требованиям.
Во-первых, для запуска TS (точнее JS) нужно отдавать код в какой-нибудь V8 или IE, при этом теряется возможность отладки того, что происходит внутри.
Во-вторых, этот код непрерываемый «по-хорошему», только убийством фонового потока, В Решарпере все анализы прерываются на тайпинг любого символа в документе, вывод типов может запрашиваться 100-1000 раз на каждое изменение документа, и почти всегда это работает мгновенно, чего не скажешь о студии, которая вешает хайлайтинги в TS документе с задержкой около секунды.
В-третьих, когда мы имплементируем поддержку TS (как и других языков), мы руководствуемся спекой. А у компилятора TS мы выявили немалое кол-во расхождений со спекой языка (и репортили баги, конечно же). Было немало случаев, когда логику работы компилятора мы понять не смогли вообще (она не сходилась со спекой) и в разных примерах компилятор выдавал неадекватные результаты, например в отношении сравнения рекурсивных генерических типов. Даже чтение кода компилятора к прозрению не приводило.
В-четвертых, код компилятора очень нестабильный в плане API, подстраиваться под него и разбираться в изменениях, особенно, когда взаимодействие между R# и TS комилятором не строготипизированное — очень тяжелая задача, сложность которой, зависит уже не от нас.
Есть еще много пунктов, почему мы имплементим поддержку языков сами. Да, расхождения случаются, но мы стараемся их фиксить по мере поступления баг-репортов.a553
15.04.2015 05:36Ооо, «производительный, прерываемый, асинхронный решарпер» это вообще отдельная история. Я вот работаю с проектом в 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# критикую :) Люблю очень, но некоторые моменты выводят из себя, вот и пишу :)nerzhul
15.04.2015 14:29Вы лучше шлите снепшоты) будем разбираться. Решарпер конечно более нетороплив голой студии. Но и кол-во работы, которую он выполняет (анализы, подсветки, доступность экшенов и т.д.) раз в 100 больше, чем в студии. Если ту же функциональность попробовать поднять на коде комплилятора, то все умрет на проектах в 100 раз меньших, чем у вас.
ControlFlow
10.04.2015 14:02+2У нового «стандартного» меню (который еще не зарелизен и есть только в VS2015) нет и половины функционала нашей менюшки, нет встроенного поиска, другой стандартный хоткей, другая модель сортировки и группировки, его API до сих пор переделывали в последних CTP, студийная лампочка показывается в другом margin'е редактора (в который нам нетривиально добросить свои другие индикаторы, типа юнит-тестов, рекурсии, имплементации интерфейсов) и так далее.
Интересная у вас логика!
hmemcpy
10.04.2015 11:09+1CodeRush уже переписывается на rosylin
CodeRush объявили о решении переписаться на Roslyn ровно год назад, и с тех пор тишина. JetBrains успела выпустить за это время 2 огромных релиза.
Переписывать под Roslyn это не тривиальная задача. В проекте над которым сам работал, OzCode, мы решили переписать наш семантический анализ под Roslyn (вместо NRefactory), для того что бы поддержать новые фичи C# 6 — это было очень не простое решение. Работали над этим и Июня прошлого года, и только неделю назад вышла бета v2 OzCode-а. Можно почитать о принятие решения тут.
В случае ReSharper-а — у них узне давным давно есть свой «Roslyn», переписывать продукт размера R# это суицид, и с технической точки зрения и с точки зрения бизнеса: на это бы ушло как минимум года 2 (даже если бы модели работы R# и Roslyn совпадали, а они разные), и результат был бы никаким: Roslyn умеет понимать только C# и VB, а R# поддерживает и другие языки.
kekekeks
10.04.2015 17:16-2у них узне давным давно есть свой «Roslyn»
Это вы про Nitra? Её не допилили же ещё, только сейчас пилится генерилка плагинов к R#.ControlFlow
10.04.2015 18:35+4Нет, про сам ReSharper.
ReSharper — это и есть «Roslyn», который случился на почти 10 лет раньше, изначально на managed коде, изначально с поддержкой нескольких языков (включая не CLR-языки). Единственные концептуальные отличия — у нас просто нет бэкендов (хотя можно было бы сделать) + в отличие от традиционных компиляторов мы заточены под постоянные изменения текста/AST (инкрементальность во все поля) и работу с незаконченным кодом. Все что сейчас толкает Roslyn — синтаксические деревья, семантические модели, движки dataflow-анализов, документные и проектные модели — были у нас реализованы когда Roslyn'а и в планах не было.
Но люди почему-то все равно уверены, что 10 лет технических инвестиций в это все надо просто выкинуть, а тонны кода анализов и фиксов C#/VB переписать на другое API, несовместимое с нашим привычным и используемым во всех других языках. Эх :)
PsyHaSTe
12.04.2015 15:14Я просто говорю, недавно общался с представителями CodeRush, и они клялись и божились, что уже скоро. Конечно, может быть «это всё маркетинг», но они обещали релиз в ближайшее время. Просто мне казалось, что Rosylin больше использует инфы компилятора и меньше сам что-то анализирует, за счёт чего достигается повышение производительности и потребления памяти. Сейчас же, после ответа товарищей gorohoroh и ControlFlow я уже в этом не уверен.
VenomBlood
10.04.2015 04:59У меня начиная с 9 версии появилась проблема, при включении dotTrace и всего остального помимо Resharper — студия начинает лагать при переключении вкладок. Если включен только решарпер вкладка переключается почти мгновенно, если включено все — переключение занимает минимум 1 секунду, иногда несколько секунд.
gorohoroh
10.04.2015 13:42Интересно. А можете воспроизвести проблему под профилятором и заслать нам снепшот? В соседнем комментарии написано, как это можно сделать.
Спасибо!
gorohoroh
10.04.2015 17:29Вот этот реквест, кажется, связан с вашей проблемой. Если на 9.1 воспроизведется и снимите снепшот, пожалуйста, отпишитесь в комментариях к нему.
Master_Dante
10.04.2015 14:44Есть ли в ReSharper возможность такого форматирования?:
habrastorage.org/files/bb9/cd5/ac2/bb9cd5ac20d74545bcc04d1631d3b098.png
gorohoroh
10.04.2015 17:13Коллеги сообщают, что нет, табличное форматирование не поддерживается.
Master_Dante
10.04.2015 17:27Есть ли в планах на будущее такой функционал?
gorohoroh
10.04.2015 17:41На данный момент в планах его нет, хотя когда-то его просили.
Master_Dante
13.04.2015 19:21-4Решил попробовать dotTrace. С сайта скачалась прога которая должна скачивать сам dotTrace. Это крайне неудобно мне пришлось добавлять эту тулзу в список разрешенных прог в фаерволе. В итоге вместо того что мне нужно скачался Resharper Ultimate хотя это не то, что было мне нужно, в итоге забил… а уровень раздражения вообще сложно передать.
gorohoroh
13.04.2015 19:33+2Если веб-инсталлятор доттрейса вам не подходит, то инсталлятор ReSharper Ultimate — это как раз то, что нужно: он содержит все, что необходимо для установки всех продуктов, которые покрываются лицензией ReSharper Ultimate (ReSharper, ReSharper C++, dotTrace, dotMemory, dotCover, dotPeek). Перед установкой указываете, что именно из всего этого добра вам нужно установить, и поехали.
Master_Dante
13.04.2015 23:18Вот хронология событий:
prntscr.com/6t9p2g
prntscr.com/6t9ou0
prntscr.com/6t9pad
prntscr.com/6t9pko — на лицо какой то баг, так что зря минусуете
Пустые окна, что куда установилось я так и не нашел. После чего потратил несколько минут и нашел таки прямую ссылку на ResharperUltimate ну думаю попробую рашарпер, скачал установил, захожу в меню About и вижу следующее:
prntscr.com/6t9wed
Что же будет дальше? :) уже страшно.gorohoroh
14.04.2015 01:58Нда, тут что-то определенно не так. Давайте завтра поговорю с Q&A, и если проблемы неизвестные, попытаемся воспроизвести.
Прошу прощения: так себе установка получилась.
gorohoroh
14.04.2015 20:07Можно вас попросить выдать нам логи инсталлятора? Файлы вида InstallerLogNNN в папке %UserProfile%\AppData\Local\JetBrains\Shared\v02
Можно создать реквест, можно написать в саппорт, либо здесь выдать ссылку для скачивания логов: как удобно.
Спасибо!
alexeibs
10.04.2015 15:26+1Установил Resharper С++. Солюшен из >75 проектов распарсился минут за 5-10. В целом, все работает довольно быстро. Функционал богаче, чем у Visual Assist'а. Но студия у меня сегодня 1 раз уже упала от нехватки памяти :( 32-битному процессу не хватило 4 Гб памяти.
gorohoroh
10.04.2015 17:364ГБ — это, увы, нижняя планка нынешних системных требований семейства ReSharper Ultimate, которые, честно говоря, слегка устарели.
А то, что несмотря на это оно работает довольно быстро — это хорошо и удачно.
ControlFlow
10.04.2015 18:44Было бы просто замечательно, если бы вы смогли снять снепшотик managed-хипа разожравшегося devenv.exe триалочкой dotMemory, чтобы у нас было представление что там распухло в памяти так :(
alexeibs
10.04.2015 18:47Сделаю, если упадет еще раз. Вообще последовательность была такой: запустил отладку, во время отладки попробовал найти места, где используется метод класса.
PsyHaSTe
Просто отлично! Особенно evaluate expression порадовал. Сколько раз приходилось писать маленькую консольную программку, чтобы нагенерировать каких-нибудь данных… Не создавать же каждый раз Text Template…
Вот только одно расстраивает — отсутствие возможности подключать свои библиотеки в источники резолва. То есть когда я пишу какой-нибудь var g = Graphics.FromImage(...), решарпер тут же предлагает подключить WindowsForms.dll и заюзать его, но вот стоит написать using(var client = new HttpClient()), то всё. А ведь System.Net.Http не менее важный неймспейс… Почему бы не дать пользователю возможость добавить свои dll для поиска? Неужели это так сильно на производительности сыграет или просто не было такой мысли?
benjik
Вместо маленьких консольных программок хорошо подходит linqpad. А платная версия сама находит в GACе сборки по используемым классам и предлагает их заюзать.
PsyHaSTe
Странно, у меня он почему-то знает про некоторые стандартные дллки (винформы, Numerics, System.Runtime.Serialization), а вот всё остальное подключать отказывается.
gorohoroh
Я постараюсь привести сюда автора и исполнителя этой фичи ControlFlow, который хоть сейчас и предается разврату где-то в Средиземноморье, но, надеюсь, сможет ответить на ваш вопрос.
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 не существует.
PsyHaSTe
Да, если в другом солюшене есть — действительно резолвит, спасибо за инфу.
Конечно, никто не предлагает делать кэш из полуторагигового фреймворка. Я просто думал, что можно кроме поиска по кэшу который есть сейчасть добавить возможность пользователю выбрать какие-то референсы, которые он часто использует (AccountManagment, Http, ...), то есть принудительно закэшировать десяток сборок сверху. Лично мне этой фичи и некоторым моим коллегам (которых я смог подбить на решарпер :) ) не хватает, особенно при работе с Sharepoint, потому там куча сборок, которые нужно референсить, но которые никогда в этот кэш не попадут. Не знаю, насколько фича сложна в имплементации, потому как я часто читаю Эрика, а у него любимая присказка — «вы представляете, НАСКОЛЬКО это сложно сделать» для нужных, но сложных фич и «если это так просто — напишите свою либу и пользуйтесь, не морочтье нам мозги» для простых. Поэтому я просто озвучиваю мнение независимой стороны. Ну а вы, как эксперты, сами регите, что с этим фидбеком делать — заводить фичреквест в джире или забить.