CodeRush объявили о решении переписаться на Roslyn ровно год назад, и с тех пор тишина. JetBrains успела выпустить за это время 2 огромных релиза.
Переписывать под Roslyn это не тривиальная задача. В проекте над которым сам работал, OzCode, мы решили переписать наш семантический анализ под Roslyn (вместо NRefactory), для того что бы поддержать новые фичи C# 6 — это было очень не простое решение. Работали над этим и Июня прошлого года, и только неделю назад вышла бета v2 OzCode-а. Можно почитать о принятие решения тут.
В случае ReSharper-а — у них узне давным давно есть свой «Roslyn», переписывать продукт размера R# это суицид, и с технической точки зрения и с точки зрения бизнеса: на это бы ушло как минимум года 2 (даже если бы модели работы R# и Roslyn совпадали, а они разные), и результат был бы никаким: Roslyn умеет понимать только C# и VB, а R# поддерживает и другие языки.
Нет! В этом все и дело — результаты функции выводятся CLR-профайлером встроенным в BugAid, по этому re-evaluate не происходит, и побочных эффектов не будет!
Спасибо вам за совет, действительно на данный момент плагин очень связан с семантикой того или иного контейнера. Если честно, я не люблю использовать ServiceLocator, так как он привязывает контейнер как глобальную зависимость.
Точно не могу сказать, но возможно то что вы предлагаете можно решить другим способом, например как аннотейшены в самом Решарпере — возможность нарядить ваш метод RegisterSingletonService каким нибудь атрибутом, который плагин поймет и будет считать за «родной».
Кстати идея неплохая совсем :) Но это наверное в vNext…
Проекту требуется только ReSharper SDK 6.1.x. Все остальные зависимости (например, контейнеры для тестов), должны скачатся сами при первом ребилде (установлен NuGet Package Restore).
Да, это запланировано. У меня самого такая же проблема если я открываю проект самого контейнера (Ninject, на пример) — их тесты используют те же самые типы везде, а Молдер не узнает все места где он используется. Так что починим!
Если не сложно, не могли бы Вы написать ето в issues на гитхабе?
Да, это запланировано. У меня самого такая же проблема если я открываю проект самого контейнера (Ninject, на пример) — их тесты используют те же самые типы везде, а Молдер не узнает все места где он используется. Так что починим!
Если не сложно, не могли бы Вы написать ето в issues на гитхабе?
Очень рад что плагин понравился, обязательно доработаю глюки в нем.
Поддержку контейнеров можно добавить прямо сейчас, ребята из Catel сейчас это как раз и делают.
Сам плагин работает на основе structured search Решарпера (SSR) — поиск паттернов в коде. Подробную информацию можно найти на wiki проекта на гитхабе. Там же и инструкции по расширению плагина и как добавить свой IoC/DI контейнер, и лист поддерживаемых на данный момент фичеров.
И правда, общаться с tKC на IRC это было прикольно =]
Ваш hmemcpy/[CiA]
CodeRush объявили о решении переписаться на Roslyn ровно год назад, и с тех пор тишина. JetBrains успела выпустить за это время 2 огромных релиза.
Переписывать под Roslyn это не тривиальная задача. В проекте над которым сам работал, OzCode, мы решили переписать наш семантический анализ под Roslyn (вместо NRefactory), для того что бы поддержать новые фичи C# 6 — это было очень не простое решение. Работали над этим и Июня прошлого года, и только неделю назад вышла бета v2 OzCode-а. Можно почитать о принятие решения тут.
В случае ReSharper-а — у них узне давным давно есть свой «Roslyn», переписывать продукт размера R# это суицид, и с технической точки зрения и с точки зрения бизнеса: на это бы ушло как минимум года 2 (даже если бы модели работы R# и Roslyn совпадали, а они разные), и результат был бы никаким: Roslyn умеет понимать только C# и VB, а R# поддерживает и другие языки.
Совсем недавно Микрософт выпустила бесплатную* Visual Studio Community которая да поддерживает все плагины и технологии. Туда все устанавливается.
Кстати, автор этой статьи (constructor) написал замечательную статью про плагин Agent Mulder на хабре, можно почитать здесь.
Спасибо вам за совет, действительно на данный момент плагин очень связан с семантикой того или иного контейнера. Если честно, я не люблю использовать ServiceLocator, так как он привязывает контейнер как глобальную зависимость.
Точно не могу сказать, но возможно то что вы предлагаете можно решить другим способом, например как аннотейшены в самом Решарпере — возможность нарядить ваш метод
RegisterSingletonServiceкаким нибудь атрибутом, который плагин поймет и будет считать за «родной».Кстати идея неплохая совсем :) Но это наверное в vNext…
Проекту требуется только ReSharper SDK 6.1.x. Все остальные зависимости (например, контейнеры для тестов), должны скачатся сами при первом ребилде (установлен NuGet Package Restore).
Надеюсь что через пару дней будет уже.
Если не сложно, не могли бы Вы написать ето в issues на гитхабе?
Если не сложно, не могли бы Вы написать ето в issues на гитхабе?
Очень рад что плагин понравился, обязательно доработаю глюки в нем.
Поддержку контейнеров можно добавить прямо сейчас, ребята из Catel сейчас это как раз и делают.
Сам плагин работает на основе structured search Решарпера (SSR) — поиск паттернов в коде. Подробную информацию можно найти на wiki проекта на гитхабе. Там же и инструкции по расширению плагина и как добавить свой IoC/DI контейнер, и лист поддерживаемых на данный момент фичеров.