Перенос COM-регистрации из HKLM в HKCU

Тема в разделе "WASM.WIN32", создана пользователем Rel, 18 май 2020.

  1. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.242
    В общем тут столкнулся со странной проблемой, подкиньте идей. Сделал 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, хотя эти ключи физически существуют?
     
  2. Cytrus

    Cytrus New Member

    Публикаций:
    0
    Регистрация:
    14 май 2020
    Сообщения:
    4
    А что вы сделали? 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 не пишет.
     
    Последнее редактирование: 18 май 2020
  3. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.242
    Ты не понял, COM-объект работает при регистрации из под HKLM ветки, но не работает при регистрации из под ветки HKCU. Ну хорошо, при моем переносе регистрации из HKLM в HKCU. Regsvcs.exe это и есть NET регистрилка, как и regasm.exe. Но они регистрируют NETовские COM-объекты в ветке HKLM, мне нужна регистрация HKCU, чтобы COM-объект можно было бы регистрировать от прав пользователя. Регасм в принципе можно заставить регать в HKCU, если средиректить ключи HKCR\* на HKCU\Software\Classes, возможно я в итоге так и сделаю, если не разберусь в текущей проблеме. Нетовские COM-объекты могут быть не зарегистрированы в GAC, в случае если они регистрируется как codebase.
     
  4. Cytrus

    Cytrus New Member

    Публикаций:
    0
    Регистрация:
    14 май 2020
    Сообщения:
    4
    Вот, я сейчас проверил. Переместил CLSD и ProgID в HKCU.
    Но у меня права админа. Возможно, что под учёткой, с меньшими правами зарегить будет невозможно.
    И даже использовать будет невозможно.
    Это надо смотреть локальные и групповые политики безопасности.
     
  5. ormoulu

    ormoulu Well-Known Member

    Публикаций:
    0
    Регистрация:
    24 янв 2011
    Сообщения:
    1.208
    Проблема не в x32/x64 ветках реестра случайно?
    Хз, у меня такой фокус всегда работал. Какая ОС?
    Попробуйте посмотреть OLEView или подгрузить через CoCreateInstance.
    А права на ветку реестра как выставлены? Кстати regedit всегда работает с High integrity.
     
  6. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.242
    Нет, и 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 ---
    А, все, чет туплю. Тайплиб ассоциируется с интерфейсом, а не с классом, буду дальше копать.
     
  7. ormoulu

    ormoulu Well-Known Member

    Публикаций:
    0
    Регистрация:
    24 янв 2011
    Сообщения:
    1.208
    А ну да, логично. Диспинтерфейсы это те которые можно дернуть через IDispatch, что и делают скрипты, в том числе wscript. Automation-compatible это вроде те что можно встраивать как документ в окно Automation контейнера. Для них соответственно требуются библиотеки типов. Наверное надо включить мониторинг не по regsvcs.exe а по гуидам класса и интерфейса, и AppId еще до кучи.
     
  8. Thetrik

    Thetrik UA6527P

    Публикаций:
    0
    Регистрация:
    25 июл 2011
    Сообщения:
    860
    Это IDispatch-based интерфейсы которые реализуют определенный набор методов, которые компилятор может проверить на этапе компиляции. К примеру вместо получения DISPID по имени, можно сразу использовать нужный DISPID из библиотеки типов. Диспинтерфейс объявляется посредством ключевого слова dispinterface в IDL.

    Это интерфейсы имеющие атрибут oleautomation. Такие интерфейсы к примеру могут использовать стандартный TypeLib маршалер.
    --- Сообщение объединено, 19 май 2020 ---
    По теме https://stackoverflow.com/questions/37193356/registering-net-com-dlls-without-admin-rights-regasm
    Покажи свой reg файл и как ты его изменял.
     
  9. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.242
    Ну вообще надо было наверное в самом начале сказать, но я использую именно regsvcs, а не regasm, тк у меня там COM+ компонент. Возможно, помимо реестра он должен как то еще регистрироваться?