В общем тут столкнулся со странной проблемой, подкиньте идей. Сделал COM-объект на .NETе для простоты, зарегистрировал его с помощью regsvcs.exe, протестил, инстанциировав COM-объект в wscript.exe. Далее выгрузил ключи HKLM\SOFTWARE\Classes\<ProgId_моего_COM_объекта> и HKLM\SOFTWARE\Classes\CLSID\<CLSID_моего_COM_объекта>. Объединил эти выгруженные ветки в один рег-файл. Заменил HLKM на HKCU в рег-файле и удалил HKLM ключи из реестра. Применил рег-файл с HKCU ключами. Попытался инстанциировать его в wscript.exe и получил обратно код ошибки 800A01AD: "Невозможно создание объекта сервером". Посмотрел создались ли ключи - создались. Подумал, что может я какую-то ветку не доперенес, запустил regsvcs.exe под Process Monitor'ом и посмотрел, какие ветки реестра он создает - все ветки я перенес. Запустил wscript.exe под Process Monitor'ом и посмотрел, что он делает при инстанциировании COM-объекта - ProgID удачно находит в HKCU, считывает оттуда CLSID, потом лезет читать этот CLSID из HKCR\CLSID\<CLSID_моего_COM_объекта>, но получает ошибку NAME NOT FOUND. И так происходит два раза. При этом читать ключ CLSID из HKCU он не пытается. Я посмотрел с помощью regedit.exe, что ключ из HKCU правильно заммапился в HKCR и ключ HKCR\CLSID\<CLSID_моего_COM_объекта> на самом деле существует. Подумал, мало ли regedit.exe запускается с правами админа, попробовал прочитать его с помощью reg.exe - ключ существует и читается. Само собой и regedit.exe/reg.exe и wscript.exe я запускаю от одного пользователя. И вот на этом моменте у меня кончились идеи. Пните меня в какую-нить сторону. Что в этой цепочке пошло не так? Правильно ли я перенес COM-регистрацию из HKLM в HKCU, какие ошибки могли возникнуть тут? Почему wscript.exe не читает ключ из HKCU и HKCR, хотя эти ключи физически существуют?
А что вы сделали? DLL? Я делал с помощью специальной NET регистрилки. regasm. Находится по адресу C:\Windows\Microsoft.NET\Framework\номер версии\RegAsm.exe. Открываете её с помощью CMD, и смотрите параметры. Там надо публичный COM-интерфейс создавать, чтобы это работало. А не просто класс. Уникальный GUID, все дела. Выставлять в параматрах проекта атрибут [ComVisible(true)] Вот, почитайте документацию. https://docs.microsoft.com/ru-ru/do...ssembly-registration-tool?redirectedfrom=MSDN --- Сообщение объединено, 18 май 2020 --- И у меня он даже в GAC не зарегистрирован. Но сама библиотека должна лежать или в подпапке GAC-а или в system32. RegAsm пути в CLSID не пишет.
Ты не понял, COM-объект работает при регистрации из под HKLM ветки, но не работает при регистрации из под ветки HKCU. Ну хорошо, при моем переносе регистрации из HKLM в HKCU. Regsvcs.exe это и есть NET регистрилка, как и regasm.exe. Но они регистрируют NETовские COM-объекты в ветке HKLM, мне нужна регистрация HKCU, чтобы COM-объект можно было бы регистрировать от прав пользователя. Регасм в принципе можно заставить регать в HKCU, если средиректить ключи HKCR\* на HKCU\Software\Classes, возможно я в итоге так и сделаю, если не разберусь в текущей проблеме. Нетовские COM-объекты могут быть не зарегистрированы в GAC, в случае если они регистрируется как codebase.
Вот, я сейчас проверил. Переместил CLSD и ProgID в HKCU. Но у меня права админа. Возможно, что под учёткой, с меньшими правами зарегить будет невозможно. И даже использовать будет невозможно. Это надо смотреть локальные и групповые политики безопасности.
Проблема не в x32/x64 ветках реестра случайно? Хз, у меня такой фокус всегда работал. Какая ОС? Попробуйте посмотреть OLEView или подгрузить через CoCreateInstance. А права на ветку реестра как выставлены? Кстати regedit всегда работает с High integrity.
Нет, и wscript.exe 64-битный и дотнетовский COM-объект AnyCPU и зарегистрирован не в WOW6432Node. У меня тоже, в том то и проблема. ОС - Венда 10. Я тут посравнивал свои действия с тем, что делает regsvcs.exe, и похоже единственная разница в том, что он создает и регистрирует TypeLib для моей сборки. И похоже, что регистрация происходит в контексте другого процесса потому, что Process Monitor не видит фактов создания этих ключей от имени regsvcs.exe. При этом, если я удаляю tlb-файл, все продолжает работать. Если я удаляю ветку, которая создалась при регистрации созданного regsvcs.exe tld-файла, все продолжает работать. Никто не регистрировал TypeLib'ы в реестре от HKCU, не совсем понимаю, как это правильно делается руками? В ветке HKCU\Software\Classes\TypeLib\<guid> особо не прослеживается связи с зарегистрированным COM-объектом. И обратно, у зарегистрированного COM-объекта в ключах нет никакой ссылки на guid тайплиба. --- Сообщение объединено, 19 май 2020 --- https://docs.microsoft.com/ru-ru/wi...f-oleauto-registertypelib?redirectedfrom=MSDN Не совсем понимаю, что в данном ключе такое "dispinterfaces" и "automation-compatible interfaces". --- Сообщение объединено, 19 май 2020 --- А, все, чет туплю. Тайплиб ассоциируется с интерфейсом, а не с классом, буду дальше копать.
А ну да, логично. Диспинтерфейсы это те которые можно дернуть через IDispatch, что и делают скрипты, в том числе wscript. Automation-compatible это вроде те что можно встраивать как документ в окно Automation контейнера. Для них соответственно требуются библиотеки типов. Наверное надо включить мониторинг не по regsvcs.exe а по гуидам класса и интерфейса, и AppId еще до кучи.
Это IDispatch-based интерфейсы которые реализуют определенный набор методов, которые компилятор может проверить на этапе компиляции. К примеру вместо получения DISPID по имени, можно сразу использовать нужный DISPID из библиотеки типов. Диспинтерфейс объявляется посредством ключевого слова dispinterface в IDL. Это интерфейсы имеющие атрибут oleautomation. Такие интерфейсы к примеру могут использовать стандартный TypeLib маршалер. --- Сообщение объединено, 19 май 2020 --- По теме https://stackoverflow.com/questions/37193356/registering-net-com-dlls-without-admin-rights-regasm Покажи свой reg файл и как ты его изменял.
Ну вообще надо было наверное в самом начале сказать, но я использую именно regsvcs, а не regasm, тк у меня там COM+ компонент. Возможно, помимо реестра он должен как то еще регистрироваться?
