Компиляция BAS в .exe: сборка бота, защита скрипта и передача клиенту

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

Что делает компиляция

На выходе получается приложение, которое запускается без установленного BAS и без доступа к дереву действий. Пользователь видит окно с настройками - количество потоков, поля для ресурсов, список прокси - и кнопку запуска. Логику он не видит и изменить её не может.

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

Интерфейс - это часть работы

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

Поэтому до компиляции решите, что клиент должен менять, и вынесите это в настройки: логины, ссылки, лимиты, задержки, пути к файлам. Всё остальное оставьте внутри. Хороший ориентир - если для смены значения пришлось бы пересобирать бота, значение должно быть в интерфейсе.

Защита скрипта: что она даёт и чего не даёт

Скомпилированная сборка не показывает логику - это отсекает основной сценарий утечки, когда заказчик открывает проект и отдаёт его другому исполнителю. Для большинства коммерческих задач этого достаточно.

Но защиту стоит понимать трезво: она останавливает пользователя и конкурента, а не подготовленного реверс-инженера. Практический вывод один и простой: не храните в скрипте то, что нельзя отдать. Ключи от ваших API, пароли от вашей инфраструктуры, приватные токены - всё это в боте на чужой машине рано или поздно окажется в чужих руках. Если боту нужен доступ к вашему сервису, давайте ему отдельный ключ с ограниченными правами, который вы сможете отозвать.

Перед передачей клиенту

Пройдите короткий чек-лист - он экономит недели поддержки:

• Пути только относительные. Абсолютный путь вашей машины у клиента не существует.
• Ресурсы приложены. Всё, что бот читает, должно ехать вместе с ним или создаваться при первом запуске.
• Ошибки объяснимы. Клиент не станет читать стектрейс - сообщение должно говорить, что сделать: «прокси не отвечает», «файл со списком пуст».
• Логирование включено. Когда у клиента что-то сломается, лог - единственное, что вы получите. Пишите в файл, а не только на экран.
• Ограничения проверены на чужой машине. У клиента другой процессор и другая память: число потоков, комфортное на вашем ПК, у него может не поехать.

Почему собранный бот ведёт себя иначе

Расхождение между студией и сборкой почти всегда сводится к трём причинам.

Пути и файлы. В студии проект лежит в известной папке; после сборки структура другая. Всё, что читалось по абсолютному пути, ломается.

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

Окружение. Другая ОС, другая версия, другой антивирус. Автоматизирующее приложение с докачкой компонентов - типичный кандидат на ложное срабатывание, и клиента стоит предупредить заранее, а не после первого звонка.

Версии и обновления

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

Поэтому договаривайтесь об обновлениях на входе, а не после поломки: как вы доставляете новую версию, кто платит за адаптацию под изменения сайта и сколько живёт поддержка. Бот, отданный «навсегда» за фиксированную сумму, превращается в бесконечное обязательство ровно в тот день, когда сайт обновит фронтенд.