При создании любого COMОбъект`а &НаСервере при запуске через автономный сервер (8.3.19.1079)
Например:
WshShell = Новый COMОбъект("WScript.Shell");
Сообщить(WshShell.CurrentDirectory);
Всегда возникает ошибка:
-2147221008(0x800401F0): Не был произведен вызов CoInitialize.
Запускал ibsrv.exe от Администратора и как приложение, и в качестве службы.
Словно ibsrv.exe ограничен в правах или в нём отсутствует работа с Component Object Model.
Словно ibsrv.exe ограничен в правах или в нём отсутствует работа с Component Object Model.
Именно так, RTFM:
Автономный сервер не поддерживает следующие возможности:
...
Работу с информационной базой с использованием внешнего соединения (COM-соединение).
...
Управление сервером с помощью COM-объекта V83.ComConnector.
(2) Но ведь я и не пытаюсь использовать внешнее соединее для программного доступа к данным 1С:Предприятия из внешних приложений, не использую COM-объект V83.COMConnector.
В мануале, в обоих случаях идёт речь о подключении к 1С:Предприятие (работа с ИБ, использование конкретного объекта V83.ComConnector)?
В мануале, в обоих случаях идёт речь о подключении к 1С:Предприятие
Разве? А вот это о чем:
Управление сервером с помощью COM-объекта V83.ComConnector.
Вы с помощью WScript.Shell что собираетесь делать? Не сервером управлять? И, может быть, документирован только запрет на V83.COMConnector, а другие виды COM отрубили "за компанию"?
Впрочем, я лишь делаю предположения, а вы - видите результат. ;)
Или я не верно трактую ограничения и они наложены на все COM?
Понятия не имею - как и вы, могу только гадать.
Но, думаю, что на все - то ли случайно так у 1С получилось, то ли специально решили на корню зарубить всех "хитрецов", которые неизбежно будут пытаться обойти неполные ограничения.
"Работа" - понятие растяжимое, не зная точно вашу задачу, могу предложить как вариант - попробовать обойтись вообще без COMОбъект: https://infostart.ru/1c/articles/590918/
(1) так автономный сервер и не должен работать с хостом напрямую. Это же вид виртуализации. Не удивлюсь, если он сделан на базе openVZ или docker. И не факт, что там усеченная версия винды, а не линукса. Последнее наиболее вероятно.
В настоящее время автономный сервер находится в статусе бета-версии.
Вообще, а что мешает поставить обычный IIS или Apache? И проблема с лицухой серверной (не более 3-х подключений) пропадет, и с СОМами проблем не будет (он сам по себе та еще проблема).
(13) Все так. И Linux будет рад отсутствию Com.
Но все костылики - отнимают много времени, например, COMОбъект("VBScript.RegExp") для парсинга полноценно вообще сложно заменить, читать .doc (не .docx) тоже ещё та затея...
Да, всё можно, но по соотношению затраченное время и результат, - иногда дешевле ComОбъект'ы
А так да! Лучше бы без них ))
апример, COMОбъект("VBScript.RegExp") для парсинга полноценно вообще сложно заменить, читать .doc (не .docx) тоже ещё та затея...
По поводу регулярок, то не совсем понятно, зачем они для парсинга - есть XPATH в DOM, хотя для HTML это работает очень относительно (придется выкидывать половину текста и дополнять незакрытые теги). С другой стороны, часто и СтрНайти оказывается достаточно. Но да, с регулярками тут проще.
По поводу ворда, то не совсем понятен смысл. Если заполнить документ, то сохранить в ворде можно и средствами 1С. А если что-то прочитать оттуда, то и XML запарсить (благо тут уже не одна библиотека для этого есть, да и XPATH тот же).
Но все эти DOC(X)/XLS(X) - это какая-то системная проблема, т.к. пользователю приходится зачем-то помимо учетной системы использовать офисные пакеты. Обычно это или большая OLAP-таблица, которую крутят ТОПы, или это договор в ворде, который с какой-то целью будет исправляться (тогда непонятно, зачем тут 1С вообще?)