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!

 

 

 

Тихое обновление с ClickOnce Video

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

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

 

Hard’n’Heavy!

 

 

Тихое обновление с ClickOnce

Сложность 200

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

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

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

Подробнее

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.
Проблем с физической публикацией не возникло. Т.е. на сервер складываются разные версии приложения, но при установке пользователю, одна версия затирает другую.

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

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

Подробнее