Could not find required file ‘setup.bin’

Да, вот такое странное название для не менее странной проблемы, когда на «чистой» машине не собирается проект для публикации с помощью ClickOnce.

Совсем недавно, при разборе проблемы с применением PostSharp при сборке на билд-сервере, столкнулся с проблемой, что на чистой машине, где стоит только сам билд-сервер TFS, новый фреймворк с SDK не собирается проект. Полностью сообщение об ошибке выглядело следующим образом:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (4486): Could not find required file ‘setup.bin’

После того, как первое недоумение прошло и раскопки файла .targets тоже ничего не дали, решено было обратиться к гуглу и он выдал удивительные вещи. Оказывается установленного ПО недостаточно для сборки ClickOnce.

Ручным решением проблемы может быть следующее:

1. Необходимо скопировать с машины разработчиков всю папку c:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A

2. Далее в регистре прописать\создать ключ HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\11.0 со значением C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper\

После чего все заработает.

Очень странное поведение и решение для линейки последних продуктов Microsoft, но что поделать. В общем и целом я полностью поддерживаю практику того, что билд-сервер должен быть максимально чист от инструментов разработчика, но по всей видимости самым лучшим решением будет поставить на билд-сервер последнюю версию студии с которой вы работаете и не задумываться над описанной проблемой. Возможно может всплыть что-то еще, от того, что студия не установлена на билд-сервере.

Но по прежнему не стоит ставить на билд-сервер инструменты вроде DevExpress, Telerik и так далее, потому что только на машине пользователя вы обнаружите, что не хватает какой либо библиотеки для отображения супер-таблицы или иных красивостей.

Так что будьте прагматичны и руководствуйтесь логикой и ситуацией, а не просто выполняйте бездумно правила и рекомендации.

 

Hard’n’Heavy!

 

 

 

TFS Aggregator

Или как автоматизировать некоторые действия в TFS 2010.

Сразу скажу, что для TFS 2012 автор обещает быстро выпустить обновленную версию, однако, на мой взгляд, с учетом того, что API не поменялось или мало поменялось, то данный небольшой проект вполне может завестись и на новом TFS 2012 RC.

Идея

Последние статьи повествуют о настройке шаблонов процессов для TFS, но данные шаблоны оторваны друг о друга, по сути, хотя и связываются в работе связями типа: Child, Parent, Related To и так далее. Было бы логично использовать эту связь, для добавления интерактивности во всю схему, чтобы элементы действительно были связанны, чтобы они действительно реагировали на состояния друг друга в зависимости от типа связи и состояния. Чтобы можно было делать некоторые аккумулирующие подсчеты в метриках, ведь все эти данные доступны и их можно использовать в автоматическом режиме, сокращая время рутинных действий.

Можно придумать достаточно много сценариев, когда автоматизация смены состояний в связанных элементах экономила бы время. В стандартной схеме, при смене состояния возможно изменение полей принадлежащих этому же рабочему элементу, но этого мало.

Например, представим себе ситуацию, когда пользовательская история имеет полный набор артефактов и готова к работе, созданы конкретные задания для реализации этой истории. В данной ситуации история находится в состоянии Ready For Development, а все задачи в состоянии Proposed. Разработчик берет задачу в работу, меняет ее состояние на Active. Далее он должен поменять состояние истории на WIP (Work In Progress). Однако этот шаг ведь можно автоматизировать! А автоматизация в свою очередь ведет к большему порядку и красоте. Т.е. как только разработчик взял задачу в работу, состояние всей истории поменялось автоматически!

Или еще пример, например работу над всей историей было решено приостановить, так как внезапно выяснились новые обстоятельства работы какого-либо компонента. В работе находятся несколько задач, какие-то еще не начаты, какие-то завершены. При переводе истории в статус Hold, по-хорошему надо и все активные задачи перевести в статус Hold. Вручную это делать было бы несколько утомительно – это тоже можно автоматизировать. Или же обратную ситуацию, когда одна задача ставится на Hold, и вся история ставится в состояние ожидания.

Так же полезным функционалом было бы, когда все задачи решены, то статус истории автоматически переходит в состояние Resolved.

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

Подробнее

Шаблон Agile в TFS2010 и TFS2012

После всех описаний существующего шаблона и модификаций для TFS2010, сподобился посмотреть, как это все выглядит в новом TFS, тем более что совсем недавно вышел Release Candidate и его можно поставить локально, чем я и занялся на досуге. Результатом был приятно удивлен.

Вместе с TFS2012 RC вышел и TFS Power Tools для него, что позволяет наглядно отобразить схему перехода состояний. Схема работы с TFS Power Tools не изменилась, так что сразу перейдем к рассмотрению различий.

Первое, что бросается в глаза, это более широкий набор рабочих элементов.

Некоторые элементы были переименованы, некоторые ушли, некоторые появились, рассмотрим, как элементы из TFS2010 соответствуют элементам из TFS2012:

Назначение TFS2010 TFS2012
Основной рабочий элемент, единица работы. Task Task
Запрос на новый функционал, бизнес-история. User Story Product Backlog Item
Баг Bug Bug
Затруднение в работе Issue Impediment
Тестовый сценарий Test Case Test Case
Общие шаги для тестовых сценариев Shared Steps Shared Steps

Подробнее

Настройка процессов в TFS – II

В прошлый раз я рассказал о том, как, на мой взгляд, должны выглядеть карты процессов для пользовательской истории, задачи, бага (UserStory, Task, Bug). В этот раз я хочу рассказать, как все это настроить в Visual Studio.  Все описанные манипуляции производятся над TFS2010 с установленным пакетом TFS Power Tools. Предполагаю так же, что вам понадобятся права администратора TFS.

После установки TFS Power Tools, в VS должен появиться новый пункт в меню Tools.

На скриншоте уже показано, что необходимо сделать для того, чтобы начать редактировать элементы задач. Tools > Process Editor > Work Item Types > Open WIT from Server. Такой выбор позволит сразу получить изменения на сервере. В целом все пункты последнего меню говорят сами за себя и с минимальными экспериментами можно получить представление об их действии.

Подробнее

Настройка процессов в TFS

Сложность 100

Речь пойдет о том, как можно расширить стандартный процесс (workflow) для некоторых элементов в TFS при выборе шаблона Agile для проекта.

Стандартные настройки проекта out-of-box на мой взгляд достаточно бедны и не обеспечивают должной прозрачности, если необходимо отслеживать/контролировать работу над проектом распределенной команды, либо когда управляющий (менеджер или еще какой-нито начальник) желает видеть как идут дела с задачами. Стандартные настройки не позволяют, на мой взгляд, уверенно говорить о текущем состоянии задач.

Обычная рабочая доска (task board) имеет больше состояний, нежели базовые настройки типичных артефактов управления проектом из которых строится процесс Agile: UserStory, Task, Bug. Мне кажется это базовые вещи, которые стоит рассмотреть и дополнительно настроить, что собственно я и сделал для себя и команды.  В рассказе ниже я затрону только настройку процесса перехода состояний, не затрагивая свойства элементов. Т.е. никаких кастомизаций внешнего вида и свойств не будет.

Прежде чем двигаться дальше, расскажу, какие инструменты вам понадобятся. Все описанные манипуляции производятся над TFS2010 с установленным пакетом TFS Power Tools. Предполагаю так же, что вам понадобятся права администратора TFS.

Подробнее

TFS2011 – Создание проекта и настройка билд-сервера

После того, как я побывал на TechEd 2011 Russia, я получил заветный купон с промо-кодом для регистрации на http://tfspreview.com, где можно попробовать новый TFS в действии как сервис. По правде сказать, TFS можно теперь поставить себе локально и смотреть на него, и любоваться. Впрочем далее по тексту вы увидите, что TFS придется качать и устанавливать, но я задействовал только контроллер сборки.  Про новый TFS можно сказать много слов, но лучше всего описывает характеристика в духе: «Секси-секси!»

В этот раз я хочу рассказать о практических аспектах настройки Team Foundation Server 2011, от создания проекта до настройки билд-сервера. Вообще я изначально хотел настроить только билд-сервер, так как без него счастье было бы не полным. Дальнейшее повествование не решает каких-то супер-сложных проблем, единственно что порой некоторые моменты не совсем понятны, но для этого статья и пишется.

Далее будет много картинок и совсем немного  текста.

Подробнее

ClickOnce, WPF, MSBuild и несколько окружений — II

Подготовка к трансформации проекта

Чтобы у нас все получилось, потребуется скачать и установить на машине билд-сервера MSBuild Community Tasks Project, так же советую его поставить и на своей машине, для экспериментов и быстрого доступа к файлу справки. Данный пакет позволяет обращаться к реализации массы наиболее часто востребованных функций во время преобразований в процессе построения приложения с помощью MSBuild. Пакет устанавливается по адресу C:\Program Files (x86)\MSBuild\MSBuildCommunityTasks, это чтобы вы быстро нашли справку по новым доступным задачам.

Канон

Так уж получается, что мы вносим серьезные изменения в процесс сборки приложения, и как все хорошие разработчики будем отделять мух от котлет, т.е. почти все существенные изменения будут производиться в отдельном файле.

MSBuild при сборке проекта руководствуется сложным набором правил и указаний, которые мы можем модифицировать или дополнять. Основные указания о сборке проекта содержаться в файле Common.CSharp.targets – который менять каким-либо образом крайне не рекомендуется. По принятому соглашению, все дополнения и расширения, касающиеся построения приложений должны иметь расширение .targets, по сути это XML файл.

Подробнее

ClickOnce, WPF, MSBuild и несколько окружений — I

Или сказ о том, как сделать публикацию приложений в один клик на разные окружения для тестирования разных версий приложений на WPF с помощью ClickOnce и TFS 2010.

На днях мне нужно было решить следующую, на мой взгляд, достаточно распространенную задачу, по размещению двух версий приложения. Одна версия QA – для тестирования текущих наработок, то, что реализуется каждый день: UI, логика, исправление мелких ошибок. Другая версия – Prod – для тестирования общих алгоритмов на реальных данных. В целом стандартная практика в мире разработки.

Решение этой задачи оказалось не столь стандартное и простое как я ожидал, для такой задачи. Но обо всем по порядку.

Диспозиция

В качестве исходных данных мы примем то, что у вас есть работоспособное приложение на WPF (для WinForm будет то же самое, но WPF более сложный случай), которое можно локально собрать в нескольких конфигурациях: Dev, QA(Cons), Prod.  Не важно, что именно у вас зависит от конфигурации, в общем случае, скорее всего это строки соединения с базой данных, оптимизация и логирование ошибок/действий пользователя.

Так же, как дополнительное условие, все конфигурации должны собираться на билд-сервере, в данном случае на TFS и при использовании MSBuild. То, что дальше описывается можно собирать локально, с помощью командной строки. Так что TFS – усложнение задачи, которое будем принимать во внимание.

И еще у вас успешно настроена на публикацию из VisualStudio с помощью ClickOnce хотя бы одна конфигурация приложения.

Еще раз, у нас есть:

  • WPF приложение
  • У приложения несколько рабочих конфигураций
  • Все конфигурации компилируются на билд-сервере (TFS)
  • Хотя бы одна конфигурация публикуется с помощью ClickOnce из VisualStudio

Проблема

В описанной системе все хорошо, все собирается на TFS, в разных конфигурациях. Т.е. я могу в любой момент получить рабочее приложение с любой конфигурацией. Однако распространение для пользователей идет только по линии QA. До определенного этапа разработки этого хватало. Теперь же надо опубликовать Prod, при этом на одном компьютере должны одновременно стоять как QA версия, так и Prod.
Проблем с физической публикацией не возникло. Т.е. на сервер складываются разные версии приложения, но при установке пользователю, одна версия затирает другую.

Кроме этой проблемы вам придется решить еще ряд других, не менее важных задач, как например обеспечение версионности приложения.

Надеюсь, что проблема ясна, но я более подробно покажу еще раз, как приходят к этой ситуации и как ее решить во всех подробностях.

Подробнее