Управление из другой программы, поддержка DotNet



  • Пожалуйста, подскажите, как лучше реализовать управление BAS-ом из другой программы?

    Хотелось бы сделать многопоточный шаблон на поддерживаемом скриптовом языке (не диаграммами).

    А потом управлять его запуском с некоторыми параметрами и остановкой, наверно, через XML RPC.
    Кроме того нужна связь скрипта во время его выполнения с СУБД (не монго как у вас), а например, хотя бы с MSSQL. Входные и выходные параметры можно передавать через базу данных.

    Еще вы упоминали в RoadMap, что появится поддержка C# к 1 мая, если не ошибаюсь, т.е. завтра :) ? Тогда бы можно было сразу nHibernate прикрутить.

    Видел, что вы ищите программистов для GTK, судя по всему планируете релиз под Linux?
    Зачем он если под WINE и так нормально работает?

    Что там будет с поддержкой DotNet? Будет ли поддержка .NET Core Standard 2 на линупсе в BAS для создания скриптов шаблонов?



  • @sanyo said in Управление из другой программы, поддержка DotNet:

    Пожалуйста, подскажите, как лучше реализовать управление BAS-ом из другой программы?

    В скомпилированных скриптах есть возможность запускать их выполняя c аргументом silent RemoteExecuteScript.exe --silent В этом случае скрипт на БАС стает консольным приложением, которым можно управлять из любого языка.
    Важно помнить, что запуск скрипта нужно проводить из той же папки, где лежит RemoteExecuteScript.exe.

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

    Редактировать параметры скрипта можно редактируя файл appslocal/SID*/engine/Actual.xml в папке скомпилированного скрипта перед запуском.

    Вот кусок хмл, который отвечает за ключ антигейт
    0_1494131117438_AntigateKey.png

    XML RPC

    БАС такого не поддерживает, но есть возможность запускать файл с браузером(Worker\Worker.exe) отдельно и передавать общаться с ним как раз через XML RPC, команды передаются через windows pipes, для сжатия использую https://github.com/google/snappy.

    Вот файл со списком всех команд
    https://github.com/bablosoft/BAS/blob/master/ChromeWorker/commandparser.cpp#L66-L73
    Там выделена команда, которая грузит урл

    Вот ман по пайпам
    https://msdn.microsoft.com/ru-ru/library/bb546085(v=vs.110).aspx

    Кроме того нужна связь скрипта во время его выполнения с СУБД (не монго как у вас), а например, хотя бы с MSSQL.

    Для MSSQL нужен отдельный модуль, либо ждать поддержки C#, а чем монго не устраивает?

    Входные и выходные параметры можно передавать через базу данных.

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

    Еще вы упоминали в RoadMap, что появится поддержка C# к 1 мая, если не ошибаюсь, т.е. завтра :) ? Тогда бы можно было сразу nHibernate прикрутить.

    К срокам я обычно не успеваю, но порядок такой, как там написано.

    Видел, что вы ищите программистов для GTK, судя по всему планируете релиз под Linux?
    Зачем он если под WINE и так нормально работает?

    Чтобы убрать оверхед от использования вайна.

    Что там будет с поддержкой DotNet? Будет ли поддержка .NET Core Standard 2 на линупсе в BAS для создания скриптов шаблонов?

    На windows будет возможность выполнить С# код из БАС, код будет крутиться в отдельном процессе, так что проблем со стандартами быть не должно. Про линукс пока ничего сказать не могу, я бы хотел, чтобы порт под линукс делал отдельный человек.



  • @support said in Управление из другой программы, поддержка DotNet:

    @sanyo said in Управление из другой программы, поддержка DotNet:

    Пожалуйста, подскажите, как лучше реализовать управление BAS-ом из другой программы?

    В скомпилированных скриптах есть возможность запускать их выполняя c аргументом silent RemoteExecuteScript.exe --silent В этом случае скрипт на БАС стает консольным приложением, которым можно управлять из любого языка.
    Важно помнить, что запуск скрипта нужно проводить из той же папки, где лежит RemoteExecuteScript.exe.

    а что подразумеваете под "стает консольным приложением, которым можно управлять из любого языка", в каком смысле управлять? кильнуть и запустить заново или можно ему как-то передавать команды?

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

    Редактировать параметры скрипта можно редактируя файл appslocal/SID*/engine/Actual.xml в папке скомпилированного скрипта перед запуском.

    пытался именно таки делать, но в каждом индивидуальном случае папка имеет вид SID{project_hash} и каждый раз приходится менять путь в моей утилите для смены параметров запуска. Пока придумал только лишь получать все параметры добавляя "ресурс по УРЛ". Иначе идей пока нет.



  • @Sevenup said in Управление из другой программы, поддержка DotNet:

    а что подразумеваете под "стает консольным приложением, которым можно управлять из любого языка", в каком смысле управлять? кильнуть и запустить заново или можно ему как-то передавать команды?

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

    пытался именно таки делать, но в каждом индивидуальном случае папка имеет вид SID{project_hash} и каждый раз приходится менять путь в моей утилите для смены параметров запуска. Пока придумал только лишь получать все параметры добавляя "ресурс по УРЛ". Иначе идей пока нет.

    SID{project_hash} - хоть имя папки меняется при смене содержимого проект, но это единственная папка, можно привязаться к этому.



  • подскажите, как корректно использовать {project_hash}? при выводе в лог отображается просто строка {project_hash}

    также есть проблема с ресурсами:
    например есть ресурс путь к папке или любой другой.

    • первый запуск ручной, устанавливаю пути
    • последующие запуски с --silent проект уже не компилируется, ресурсы берутся из actual.xml
    • если заменить project.xml и снова запустить с --silent создается новая папка SID{project_hash} в которой в actual.xml уже нет прежних значений. т.е. снова требуется первичный ручной запуск.

    т.е. ставим крест на автоматизации процессов, только запускать в ручную.

    было бы ОЧЕНЬ здорово, если бы путь к файлу ресурса можно было указывать относительный, а не полный, например по дефолту threads.txt означало бы путь к папке запуска (там где RemoteExecuteScript.exe) проще говоря тот путь, откуда RemoteExecuteScript.exe берет project.xml для компиляции.

    Либо как вариант, иметь константу пути, откуда RemoteExecuteScript.exe берет project.xml и возможность использовать ее в указании пути ресурса.

    спасибо.


Log in to reply