Недавно наткнулся на очень забавный и неочевидный баг студии. Суть бага – студия начинает подвисать при сохранении aspx/ascx файлов секунд так на 20-30. Через полминуты все проходит, и можно работать дальше. Воспроизводится стабильно, простым нажатием Ctrl+S. При этом студия не подвисает намертво, просто не отзывается на действия, и вот значок сохранения не пропадает из статус бара:

CropperCapture[2]

Запускаем второй экземпляр студии. Снимаем в DebugOptions and Settings чекбокс Enable Just My Code. Цепляемся им к первому экземпляру студии:

Options

attach

Нажимаем Ctrl+S в проблемном экземпляре студии. Видим в Output кучу исключений:

NotFound

Включаем в DebugExceptions остановку при бросании System.IO.FileNotFoundException. Сохраняем еще раз, смотрим на детали исключения:

breakRegion

В проекте нет явных ссылок на antlr.runtime. Но есть ссылка на DDay.iCal, которая хоть и ссылается на antlr, но не требует ее для нормальной работы. Распространяется DDay, естественно, без проблемной сборки.

При сохранении aspx-файла студия пытается пересоздать файл aspx.designer.cs. Для этого ей нужно получить типы всех элементов управления, упоминаемых в разметке. Например, студия видит в разметке элемент вроде:

Region2

Для получения конкретного типа PostBackTriggerControl студия берет список нейспейсов с префиксом lsf из конфигурации, и пытается найти каждую комбинацию “namespace.type”. А неймпейсов с префиксом lsf у нас оказалось много:

config

Студия достаточно быстро находит нужный ей LogicSoftware.EasyProjects.Web.Gui.Code.PostBackTriggerControl в сборке LogicSoftware.EasyProjects.Web.Gui.Code. Но на этом она не останавливается.

На всякий случай студия предпринимает попытки найти тип PostBackTriggerControl еще и во всех явно или косвенно упоминаемых сборках. Даже если сборка явно задана при регистрации неймспейса. Если тип найден, он запоминается в кэше. Поймав при поиске FileNotFoundException, студия забывает сохранить правильный результат в кэш.

Бешенное количество попыток – количество элементов на странице * количество регистраций неймспейсов * количество сборок на которые ссылается сайт * количество проблемных сборок -  и дает те самые 210 исключений при одном нажатии Ctrl+S. Исправляется подбрасываеним недостающих сборок в папку с зависимостями. Добавлять ссылки из web-проекта на них или копировать bin – необязательно. Достаточно, чтобы студия увидела их при поиске.

Стандартный отчет Scrum Burndown никак не учитывает выходные при построении тренда. В Q and A для шаблона есть решение по учету выходных от Tore Østergaard, но оно требует предварительной сборки.

Готовый к использованию fix:

1. Скачать исправленный Report Definition.

2. Открыть Report Site:

image

3. Залить обновленный Report Definition:

image

image

4. Просмотреть отчет. На месте выходных тренд должен принять горизонтальное положение:

image

Наткнулся на забавный глюк – студия стала намертво подвисать при попытке открытия web.config rewrite-файла. После перезапуска файл открывался вполне нормально, но через некоторое время зависон повторяется. Убивание suo/user не помогло.

Поковырял ее отладчиком, и выяснил что висит она на SqlConnection.Open. Непонятно зачем, но при открытии реврайта студия пытается подсоединиться ко всем серверам, зарегистрированным в Server Explorer/Data Connection. Почистил оттуда мертвые записи – подвисания прошли.

Предыстория: в 2010-й студии появились вмеру глючные Coded UI Tests. У Coded UI есть серьезное преимущество перед Selenium/Watin – студийные тесты эмулируют клавиатуру и мышку. Selenium и Watin ограничиваются вызовом событий в javascript.

Серьезный недостаток Coded UI Tests – родная поддержка только одного браузера – IE. Поддержку Firefox можно доустановить пакетом с длинным названием Microsoft Visual Studio 2010 Test Package for Mozilla Firefox (Power Tool) Beta. Пакет позволяет записывать действия в IE, и воспроизводить их, но уже в FF.

История: и вот однажды вам захотелось попробовать эту самую поддержку Firefox. Вы выкачали пакет, установили его, прочитали инструкцию и установили аддон 😉

Запустили студию,создали новый Test Project, добавили в него Coded UI Test. Записали простейшие действия:

  1. Открыть в браузере страницу http://pashapash.com/samples/1.html
  2. Кликнуть на ссылку Click Me.

Дальше вы сгенерировали код и запустили тест. Открылось новое окно IE, мышка дернулась к ссылке и кликнула на нее. Тест позеленел.

Вы смело переключаете браузер на Firefox:

[TestMethod]
public void
CodedUITestMethod1()

   
BrowserWindow.CurrentBrowser = "Firefox"
;
   
this.UIMap.ClickLink(); 
}

Запускаете и…

  • Если вы QA-автоматизатор – откроется окно мозиллы, адрес поменяется на тестовый, мышка кликнет по ссылке :)
  • Если у вас система младше Vista/W7/2008/R2 – все тоже заработает.
  • Но если вы разработчик – то с большой вероятностью вы увидите пустое окно мозиллы и ошибку в логе:

Microsoft.VisualStudio.TestTools.UITest.Extension.PlaybackFailureException: Unable to perform actions on Mozilla Firefox. Ensure that Visual Studio Test Helper extension for Mozilla Firefox is installed and enabled. Please see the package readme for more details.

Да, вы поставили аддон, мозилла запускается, но студия не может до него достучаться.

Причина – небольшое раздолбайство авторов аддона со стороны студии. Пакет состоит из двух частей: аддона к Mozilla, и аддона к Visual Studio. Взаимодействие между ними построено следующим образом:

  • Студийный аддон выбирает случайный порт, и начинает его прослушивать.
  • Студийный аддон записывает выбранный порт в реестр и запускает браузер.
  • Аддон к браузеру читает порт из реестра, подключается к нему, и ждет команд.
  • Если со стороны браузера в течении пары секунд нет подключения – студийный аддон выбрасывает ошибку.

Раздолбайство проявляется в коде, прослушивающем порт:

IPHostEntry hostEntry = Dns.GetHostEntry("localhost");
IPEndPoint localEP = new IPEndPoint
(hostEntry.AddressList[0], port);
this.listenerSocket = new Socket(localEP.Address.AddressFamily, SocketType.Stream, ProtocolType
.Tcp);
this.listenerSocket.Bind(localEP);

Если у вас Vista/W7 – то у вас наверняка установлен IPv6. Cписок адресов для localhost – ::1 и 127.0.0.1. Адрес IPv6 будет первым в списке. Студийный аддон будет ожидать подключения только по протоколу IPv6.

Аддон со стороны Firefox так же подключается к localhost по первому попавшемуся адресу. У нормальных людей все работает. Но вы – разработчик, вы наверняка использовали встроенный в студию Web Dev Server. И Firefox при этом дико тормозил. Вы выгуглили решение – запретить Firefox-у использовать IPv6, установив network.dns.disableIPv6=true. Это официально рекомендованное решение и от Microsoft, и от Mozilla. И теперь Firefox и его аддоны не видят нужный адрес.

Самое простое решение – отредактировать C:WindowsSystem32driversetchosts, оставить (или добавить) только одну строку для localhost:

127.0.0.1    localhost

Удалить или закомментировать строку для IPv6:

# ::1        localhost

После этого тест отработает у вас не хуже, чем у QA :)

Исправлена одна из надоедливых проблем в Visual Studio: появление скролла в контекстных меню даже в тех случаях, когда места на экране хватало для отображения меню без скроллинга.

Для исправления нужно установить два патча, первый для Visual Studio, второй – для Windows Presentation Foundation.

  1. Патч Для Visual Studio 2010: http://code.msdn.microsoft.com/KB2345133
  2. Патч для Windows Presentation Foundation 4.0: http://code.msdn.microsoft.com/KB2413613
    1. X86: NDP40-KB2413613-x86.exe
    2. X64: NDP40-KB2413613-x64.exe.

Оригинальный пост в блоге Visual Studio:http://blogs.msdn.com/b/visualstudio/archive/2010/10/14/hotfixes-available-for-scrolling-context-menu-problem.aspx