Спасибо за реквесты, только что-то на меня некоторые не попали. Кастомные биндинги в 7.1 пришлось сделать костыльно через нейминг конвеншн, просто чтобы наконец они хоть как-то заработали, сделать полноценно через аннотации планируется в 8ке. Вообще резолв в маркап экстеншенах переписался полностью в 7.1, решило достаточно много проблем…
Насчёт работает медленно — когда мне присылают снепшоты с «решарпер медленный в XAML», то в 95% там торчит студийные language service для XAML или XAML-дизайнер или код проекта в design-time тормозит. Абсолютному большинству помогает переключение типа редактора в VS на «Source code», жертвуя дизайнером. Для XML у нас очень и очень быстрый рукописный парсер, в 7.1 для комплишена я сильно разогнал резолв (только первый раз после открытия проекта втыкает), так что если что-то реально втыкает, то лучше снять снепшотик — в 7.1 это делается в два клика ReSharper — Help — Profile VisualStudio, оно само аттачит ядро нашего dotTrace к студии, снимает снепшотик, само засылает на наш FTP.
XAML на C# видел в проекте кастомера, у меня его нет и показать бы не смог. Именования разруливались как-то типа var nameReference = button.WithName(«Foo»); и дальше использовался тип-референса на имя. В каждом биндинге аннотировался тип DataContext'а, насколько я помню.
Здравствуйте, на данный момент я занимаюсь поддержкой XAML в ReSharper :)
Грустно, конечно, когда часть твоей работы оценивают как «сосёт и причмокивает»… Я присоединился к JB полтора года назад джуниором заниматься поддержкой XAML, которая на тот момент была, к большому сожалению, в достаточно заброшенном состоянии — поддержку написал один очень крутой человек и стал заниматься многими другими важными вещами, уделяя время багфиксам в XAML. Полгода я только въезжал что к чему в мире R#, а остальное время пытаюсь догнать все остальные подсистемы R#, починить критические баги, да ещё и фичи успеть новые сделать… Совсем переписал code completion в 7.1, портировал из web-поддержки всякие синхронные редактирования тегов и прочие typing assit фичи, сделал поддержку WinRT (вы не представляете сколько с ней было проблем, от проекций типов WinRT до правил приведений типов в XAML-дереве), сильно улучшил вывод типа контекста в биндингах (кстати оно было ещё до 6.0, там 1200 строк чистой магии) и многое другое. А ещё мне приходится проверять каждую фичу в WPF/SL/WP7/WinRT + иногда заглядывать в Workflow Foundation с XAML2009 :) Я очень надеюсь, что поддержка стала удобнее в 7.0/7.1 и мой труд заметен. Если вам, уважаемый топикстартер, по прежнему приходится иметь дело с XAML и R#, то милости прошу ко мне на огонёк. Планов на 8.0 прилично и мне будет приятно, если я смогу хоть немного исправить ваше отношение к нашей XAML-поддержке :)
Что до вашего языка — я думаю среди активных пользователей WPF оно действительно может востребовано; персонально не люблю JSON; конечный синтакис очень краткий — замечательно; языковые конструкции очень специфичные — когда-то я смог разобраться с XAML не читая спек и документации, с вашим языком это никак бы не прокатило (что за ~?).
Что до XAML — он ужасен и монструозен. Я был бы счастлив, если бы MS заменили его чем-нибудь легковесным или хотя бы уделяли развитию WPF больше внимания, потому что за те же 6 лет, за которые вы нас ругаете (у нас меньше лет поддержке на самом деле), MS вообще ничего кардинального с XAML не сделали.
Что до решения проблемы XAML — мне кажется куда проще напедалить достойный eDSL на обычном C#. Я видел в паре проектов такие, биндинги через Expression задаются (типизированные и рефакторятся — отлично), кучка extension-методов и уже куда удобнее XAML получается, лучше подвергается декомпозиции и т.п.
Что до поддержки новых языков в R# — у нас есть SDK, но мало документации, к сожалению. Недавно вышел плагин поддержки T4, его можно использовать как пример + можно связаться непосредственно со мной и я обязательно помогу чем смогу. Но я крайне сомневаюсь в том, что затея оправдает затраченные усилия, не в MS-стеке :)
На свой страх и риск запускаете VS с ключиком /ReSharper.Internal, аннотатор находится в ReSharper | Internal | Annotator, умеет рендерить выведенные из кода аннотации в XMLники или в атрибуты в коде.
Никаких гарантий :)
Если посмотреть на утекший WP8 SDK, то «нативной» (как в Windows 8) поддержки приложений на HTML5/JS в новом WP8 не будет. То есть придётся ограничиваться только PhoneGap и им подобным, то есть обычными приложениями, состоящими из WebBrowser-контрола, что уныло.
Кстати, в VS2012 появилась асинхронная загрузка solution'ов — если раньше 300 проектов грузились аж минуты 3-5, то сейчас адские тормоза наблюдаются секунд 30 и можно уже начинать работать, а солюшен продолжает загружаться.
Я иногда работаю с солюшеном ReSharper на лаптопе (конечно же с самим ReSharper'ом), 300 проектов, лаптоп с Core i3 @ 2.5Ghz, 8Gb и SATA-II SSD — работу можно назвать близкой к комфортной.
В версию 7.0 мы встроили движок dotTrace, так что теперь вы можете оперативно снять снепшотик (ReSharper — Help — Profile Visual Studio) и буквально за пару кликов заслать его к нам, мы починим-подкрутим и все будут счастливы!
Точно по такой же причине, по которой мы разрабатываем ReSharper с помощью самых последних внутренних билдов ReSharper — чтобы непрерывно контроллировать качество и выявить как можно больше проблем силами самой команды. У Microsoft такой же подход, они многими командами сидели на VS11 за месяцы до выхода в паблик Developer Preview.
Совершенно верно. Анализ множества INPC-фреймворков показал, что выявить общий «паттерн» notify-методов не представляется возможным (везде разные базовые классы, разные имена методов, разные имена и порядки параметров, разные подходы), поэтому собственные реализации классов типа «ViewModelBase» придётся проаннотировать атрибутом [NotifyPropertyChangedInvocator]. Это не требует никаких бинарных зависимостей, реализацию этого атрибута можно просто скопировать себе в проект их наших настроек -> Code annotations -> Copy default implementation to clipboard.
Содержимое топика писал не представитель JetBrains, за его содержимое я не могу ответить.
R# 7.0 предлагает строгую типизацию строковых литералов, передаваемых в notify-метод, а это значит что Вы получаете автоматический rename и рефакторинги, навигацию сквозь этот строковой литерал, валидацию модификатора доступа таких свойств (INPC-свойства обязаны быть публичными), конвертирование обычного свойства/автосвойства в свойство с нотификацией в одно контекстное действие, массовое создание свойств с нотификациями из полей и конечно же code completion.
Всё это позволит с лёгкостью добавлять дополнительные нотификации в сеттер (второй абзац), а R# будет осуществлять типизацию, следить за rename'ами и удалениями свойств.
Более того, если notify-метод получает expression вместо строки (третий абзац), то мы помогаем вставлять в сеттер свойства нотификацию с () => Property или x => x.Property в качестве аргументов.
Особенно забавно видеть людей, у которых вот прям сейчас на билд-серверах крутится компилятор C# 5.0, на всех девелоперских машинах стоит VS2012 RC, а продакшн серьёзно юзает .NET Framework 4.5 :)
Ещё забавнее видеть людей, которые сталкиваясь с INPC, юзали настолько примитивные VM-объекты, что в них не было зависимостей между свойствами и из сеттера одного свойства не требовалось уведомлять об изменениях других вычисляемых свойств. Тут ни [CallerMemberName], ни PostSharp не поможет :)
А больше всех я люблю людей, которые юзают везде System.Linq.Expressions и когда их продукт разрастается, смотрят в memory-профайлер и удивляются почему простое присвоение свойству так гадит аллоациями в managed heap, а процессорное временя всё больше проваливается в GC :)
В любом случае, я рад, что проблема INPC обошла Вас стороной :)
когда я первый раз увидел for… else, то всё же ожидал, что else исполняется если цикл не сделал ни одной итерации — имхо это куда более ожидаемое поведение
>А найти файл в солюшене гораздо проще если сразу включить синхронизацию файла и положения в солюшене — это умеет и сама студия.
В самом солюшене ReSharper всего 300 проектов, но «track active file in solution explorer» уже ЖОСКО увеличивает время открытия файла во время навигации. Просто попробуйте отключить, на огромных солюшенах будете приятно удивлены :)
Как по мне, то у «Locate File in Solution Explorer» плюс в том, что оно открывает свёрнутый solution explorer.
1. Не обязательно. Если будете ещё использовать wimax-свисток, то оставьте.
2. Да, они не конфликтуют.
3. Сети ещё нет, никак не проверить. Может только убедиться, что в системе новый сетевой адаптер появляется и открывается страничка status.yota.ru
Насчёт работает медленно — когда мне присылают снепшоты с «решарпер медленный в XAML», то в 95% там торчит студийные language service для XAML или XAML-дизайнер или код проекта в design-time тормозит. Абсолютному большинству помогает переключение типа редактора в VS на «Source code», жертвуя дизайнером. Для XML у нас очень и очень быстрый рукописный парсер, в 7.1 для комплишена я сильно разогнал резолв (только первый раз после открытия проекта втыкает), так что если что-то реально втыкает, то лучше снять снепшотик — в 7.1 это делается в два клика ReSharper — Help — Profile VisualStudio, оно само аттачит ядро нашего dotTrace к студии, снимает снепшотик, само засылает на наш FTP.
XAML на C# видел в проекте кастомера, у меня его нет и показать бы не смог. Именования разруливались как-то типа var nameReference = button.WithName(«Foo»); и дальше использовался тип-референса на имя. В каждом биндинге аннотировался тип DataContext'а, насколько я помню.
Грустно, конечно, когда часть твоей работы оценивают как «сосёт и причмокивает»… Я присоединился к JB полтора года назад джуниором заниматься поддержкой XAML, которая на тот момент была, к большому сожалению, в достаточно заброшенном состоянии — поддержку написал один очень крутой человек и стал заниматься многими другими важными вещами, уделяя время багфиксам в XAML. Полгода я только въезжал что к чему в мире R#, а остальное время пытаюсь догнать все остальные подсистемы R#, починить критические баги, да ещё и фичи успеть новые сделать… Совсем переписал code completion в 7.1, портировал из web-поддержки всякие синхронные редактирования тегов и прочие typing assit фичи, сделал поддержку WinRT (вы не представляете сколько с ней было проблем, от проекций типов WinRT до правил приведений типов в XAML-дереве), сильно улучшил вывод типа контекста в биндингах (кстати оно было ещё до 6.0, там 1200 строк чистой магии) и многое другое. А ещё мне приходится проверять каждую фичу в WPF/SL/WP7/WinRT + иногда заглядывать в Workflow Foundation с XAML2009 :) Я очень надеюсь, что поддержка стала удобнее в 7.0/7.1 и мой труд заметен. Если вам, уважаемый топикстартер, по прежнему приходится иметь дело с XAML и R#, то милости прошу ко мне на огонёк. Планов на 8.0 прилично и мне будет приятно, если я смогу хоть немного исправить ваше отношение к нашей XAML-поддержке :)
Что до вашего языка — я думаю среди активных пользователей WPF оно действительно может востребовано; персонально не люблю JSON; конечный синтакис очень краткий — замечательно; языковые конструкции очень специфичные — когда-то я смог разобраться с XAML не читая спек и документации, с вашим языком это никак бы не прокатило (что за ~?).
Что до XAML — он ужасен и монструозен. Я был бы счастлив, если бы MS заменили его чем-нибудь легковесным или хотя бы уделяли развитию WPF больше внимания, потому что за те же 6 лет, за которые вы нас ругаете (у нас меньше лет поддержке на самом деле), MS вообще ничего кардинального с XAML не сделали.
Что до решения проблемы XAML — мне кажется куда проще напедалить достойный eDSL на обычном C#. Я видел в паре проектов такие, биндинги через Expression задаются (типизированные и рефакторятся — отлично), кучка extension-методов и уже куда удобнее XAML получается, лучше подвергается декомпозиции и т.п.
Что до поддержки новых языков в R# — у нас есть SDK, но мало документации, к сожалению. Недавно вышел плагин поддержки T4, его можно использовать как пример + можно связаться непосредственно со мной и я обязательно помогу чем смогу. Но я крайне сомневаюсь в том, что затея оправдает затраченные усилия, не в MS-стеке :)
Никаких гарантий :)
В версию 7.0 мы встроили движок dotTrace, так что теперь вы можете оперативно снять снепшотик (ReSharper — Help — Profile Visual Studio) и буквально за пару кликов заслать его к нам, мы починим-подкрутим и все будут счастливы!
R# 7.0 предлагает строгую типизацию строковых литералов, передаваемых в notify-метод, а это значит что Вы получаете автоматический rename и рефакторинги, навигацию сквозь этот строковой литерал, валидацию модификатора доступа таких свойств (INPC-свойства обязаны быть публичными), конвертирование обычного свойства/автосвойства в свойство с нотификацией в одно контекстное действие, массовое создание свойств с нотификациями из полей и конечно же code completion.
Всё это позволит с лёгкостью добавлять дополнительные нотификации в сеттер (второй абзац), а R# будет осуществлять типизацию, следить за rename'ами и удалениями свойств.
Более того, если notify-метод получает expression вместо строки (третий абзац), то мы помогаем вставлять в сеттер свойства нотификацию с () => Property или x => x.Property в качестве аргументов.
Ещё забавнее видеть людей, которые сталкиваясь с INPC, юзали настолько примитивные VM-объекты, что в них не было зависимостей между свойствами и из сеттера одного свойства не требовалось уведомлять об изменениях других вычисляемых свойств. Тут ни [CallerMemberName], ни PostSharp не поможет :)
А больше всех я люблю людей, которые юзают везде System.Linq.Expressions и когда их продукт разрастается, смотрят в memory-профайлер и удивляются почему простое присвоение свойству так гадит аллоациями в managed heap, а процессорное временя всё больше проваливается в GC :)
В любом случае, я рад, что проблема INPC обошла Вас стороной :)
В самом солюшене ReSharper всего 300 проектов, но «track active file in solution explorer» уже ЖОСКО увеличивает время открытия файла во время навигации. Просто попробуйте отключить, на огромных солюшенах будете приятно удивлены :)
Как по мне, то у «Locate File in Solution Explorer» плюс в том, что оно открывает свёрнутый solution explorer.
2. Да, они не конфликтуют.
3. Сети ещё нет, никак не проверить. Может только убедиться, что в системе новый сетевой адаптер появляется и открывается страничка status.yota.ru
Для того, чтобы распараллелить ваш процесс вы не должны более плодить потоки, просто воспользуйтесь парой новых ключевых слов.Автор явно не в теме чем асинхронность отличается от параллельного исполнения.