Архивы: Microsoft

Открытие дня

Только что с прискорбием узнал, что Build Events в Visual Studio не агрегируются и поэтому не наследуются из Property Sheets. Потомушта это «simple property, not the aggregate one» (пруф).

Пичаль.

Workaround day

В 2010 студии M$ столько всего напеределывали, что создание новго проекта превратилась в поиск воркэраунда к воркэраунду. Например, зачем-то напрочь переделали определение custom build tool, причем гуй для его создания и редактирования привинтить забыли. В результате сегодня нашел, что сами  M$ рекомендуют проекты, которые используют custom build tool (ну, мало ли, вам Yacc’нуть чего надо или еще чего страшного натравить на исходники) создавать сначала в 2008 студии, а потом конвертировать в 2010.

Воистину, стоя и в гамаке. Еще и в противогазе.

К чести Студии, конвертирует она проекты без запинки.

Продолжаем есть кактус.

(English) \Microsoft was unexpected at this time

Этот пост пока не переведен на русский язык. Читать на Американский Английский

Кто о чем, а я о работе

M$ заботливо обеспечили C++ программистов годовым запасом грабель. Точнее, даже граблей — таких же кривых, как само это слово.

Сегодня компилятор мне в красках рассказывал, куда мне нужно было пройти.

Подробности позже телеграфом тчк.

Студия 2010: дневник мыши, поедающей кактус

На вкус кактус пока ничего. За прошедшие три дня студия упала три раза и два раза зависла.

Что заметно:

  • Переработали меню проекта «добавить новую хрень».  Выглядит ново, почти вебдванольно. Эргономика, правда, не изменилась.
  • Кажется, переписали Intelli(non)Sense. Как и обещали. Работает заметно быстрее и менее косячно. Впрочем, проект у нас пока в коротких штанишках, посмотрим, что будет дальше
  • IntelliSense точно если не переписали, то сурово ковыряли. По крайней мере, в предыдущих версиях она могла ставить Студию в разные позы в случае использования C++/Cli. Типичный пример — при использовании MSTest для тестирования C++ кода Студия начинала уходить в нирвану при сколько-нибудь приличном количестве тестов в проекте. В новой версии IntelliSense просто заявляет, что для C++/Cli оно работать не будет. И, что характерно, не работает.
  • MSTest теперь по умолчанию хранит результаты лишь для 25 запусков. Я, в принципе, вообще не понимаю всей этой затеи с хранениями результатов юнит-тестов. С моей точки зрения, тесты либо прошли, либо нет. Если тесты не прошли, билд не проходит тоже. End of story. В любом случае теперь, кажется, студия перестанет захламлять диск историей тестов, которая все равно никому не нужна.
  • Хост-процесс для тестов ведет себя странно. Периодически забывает завершиться, ввиду чего пересборка DLL с тестом обламывается. Подобного заскока за прежними версиями замечено не было.
  • Отладчик при работе в Mixed mode (тот самый случай тестирования С++ кода в MSTest) ведет себя неортодоксально. Норовит подвиснуть почем зря.
  • Зачем-то сломали поведение «Project dependencies». Теперь, чтобы подсунуть линкеру другую статическую либу из этого же солюшена, нужно проект с библиотекой добавить в рефересы проекта. Совсем как в C# проектах. Немного неожидано. Зависимости проекта оставлены лишь для определения порядка сборки.

VS 2010: полет нормальный

Все идет четко по плану

DEP

За будущее разработки ПО я совершенно спокоен!

Неортодоксальные текстовые редакторы рулят

Как истинный приверженец vim, я устанавливаю его первым делом на любой мой рабочий компьютер с Майкрософт Уиндоуз, чем раз и навсегда отбиваю у коллег всякое желание что-либо делать на нем без меня. Очень, очень полезное свойство, но люблю я vim вовсе не за это.

Наступил я сегодня на грабли. Впрочем, наступил на них я уже давно, согласившись писать юнит-тесты для C++ кода на MSTest, но сегодня я нашел особо детские грабли.

Полагаю, что некоторые особо просвещенные читатели моего уютного бложека в курсе, что MSTest позволяет «облегчить» написание так называемых Data-Driven юнит тестов. Как обычно, облегчение это приходит в полном соответствии с корпоративным стандартом майкрософт — «теперь  выстрелить себе в ногу стало еще легче». Казалось бы, прикрепи себе атрибут [DataSource] перед тест-кейсом и вперед, на танки мегабайты входных данных, что может быть прекраснее?

Откуда же я знал

Еще одна причина, почему shelves в TFS лучше не пользоваться.

Я уже как-то писал, что «изобретатель» shelves в TFS — по всей видимости человек, одаренный особыми, неподвластными нам, простым смертным, качествам. По сути наличие в системе контроля версий «возможности» временно сохранить что-о  не в репозитории, а в каком-то странном четвертом измерении противоречит самой идее системы контроля версий. Какой такой идее, спросите Вы? Да очень простой — изменил код — коммить изменения. Если коммитить нельзя (кто сказал, что нельзя? Плюнь ему в рожу!), все равно коммить. Займи, но выпей, то есть, создай свой бранч, но коммить!

Отступления от этого правила, впрочем, обычно ни к чему плохому не приводят. Однако, вы видели хоть один программный проект, который протекал бы как обычно? Нюанс, как говорится в анекдоте.

Зарисовка с натуры — продукт ушел в печать, код заморожен. Релиз уже завтра (или позавчера), и тут тестеры находят баг. Или бажище. Или Баг Шредингера, который проявляется только в 50% случаев, если его искать специально. Как бы то ни было, баг есть. Исправить его — тоже «есть». А вот теперь тот самый нюанс — коммитить изменения в основное дерево низзя!  Особенно если проект большой и тяжелый, решение о том, как и в каком виде подавать багфикс, может приниматься на самом верху — то ли хотфикс выпустить, то ли сервис-пак готовить, то ли забить и ждать новой версии. Пока политки играют в свои игры, программисты у себя в подвале решили изменения в shelve положить, дабы собрать-протестировать-провести code review. Сказано — сделано. А тут, не прошло и полгода, большие боссы постановили — сервис-паку быть!

Недолго думая, сделали бранч. И… обломались очень жестко. TFS позволяет делать unshelve’ код только в ту же ветку, откуда ему сделали shelve. И никак иначе. С SVN все проще, чем два байта переслать — svn copy, svn switch и следующий коммит будет уже в новую ветку. TFS же, к счастью, предлагает возможность сделать unshelve в другую ветку. Если установлены TFS power toys (как? У Вас еще не  установлены?), без которых в TFS 2005 даже банальнейшего tree difference нет, то можно из командной строки сделать tfpt unshelve /merge. К несчастью, это не всегда работает — в моем случае попытка завершалась маловразумительным сообщением вроде «Cannot determine workspace».

Решать проблему пришлось дедовским методом — доставать beyond compare и тупо сравнивать каталоги на диске. Кстати, если кто рискнет повторить сей трюк — сделать зарание Check-out всего дерева в той ветке, куда собираемся коммитить — очень, очень хорошая идея.

(English) Pause for X seconds in batch file?

Этот пост пока не переведен на русский язык. Читать на Американский Английский

Sleep в командной строке?

Почему-то второй раз за пару дней потребовалось организовать «паузу на X секунд» в bat файле. Что характерно, стандартная команда pause делает совсем не то, на что намекает ее название.

Попытки вызвать sleep или wait приводили только к осознанию скорбного факта, что мы работать вынуждены вовсе не под *nix-ом. Cygwin ставить тоже не с руки, хотелось бы, чтобы скрипт работал везде и по возможности без применения бубнов, танцев и других оккультных атрибутов.

Знаете, как проблема решилась?

ping -n 2 127.0.0.1 > nul

(тут спим две секунды)

Все гениальное просто. (?)

7 посетителей онлайн
2 гостей, 5 bots, 0 зарегистрированных
Максимум сегодня:: 20 в 02:44 am UTC
В этом месяце: 40 в 06-04-2017 04:12 pm UTC
В этом году: 50 в 02-12-2017 07:56 am UTC
За все время: 130 в 10-22-2014 11:16 pm UTC