Мы столкнулись с довольно странной проблемой с нашим COM-компонентом. Компонент реализует общеизвестный интерфейс и используется сторонним продуктом с закрытым исходным кодом (в дальнейшем именуемым Продукт X). Продукт X настраивается через реестр Windows. Продукт X считывает реестр и находит идентификатор класса нашего компонента.
Наш компонент - 32-битный in-proc, реализованный на нативном C ++ с использованием ATL, и мы регистрируем его в COM + в 64-битных системах, чтобы он активировался в суррогатном процессе.
Теперь продукт X не может использовать наш компонент и отслеживает E_ACCESSDENIED в журнале событий Windows, и мы также видим следующее сообщение об ошибке
Настройки разрешений для конкретного приложения не предоставляют права локальной активации для приложения COM-сервера с CLSID {идентификатор класса COM-объекта здесь} и APPID {идентификатор приложения приложения COM + здесь} для пользователя MACHINENAME \ administrator SID (SID здесь) с адреса LocalHost (используя LRPC). Это разрешение безопасности можно изменить с помощью инструмента администрирования служб компонентов.
в системном журнале.
Это похоже на проблему с разрешениями. Итак, мы создали программу «Hello, world» на C #, которая new является COM-компонентом и вызывает из него один тривиальный (никогда не сбойный) метод:
компонент OurComponent.IOurComponent = новый компонент OurComponent.OurcomponentClass ();
component.TrivialMethod ();
Когда эта программа запускается из той же учетной записи, что и продукт X, она работает нормально - создается экземпляр компонента, и мы даже видим, как в консоли COM + вращается «зеленый шар с плюсом».
Таким образом, у нас есть две программы, запущенные на одном компьютере под одной и той же учетной записью пользователя, и одна может создать экземпляр компонента COM, а другая - нет. Что может быть причиной этого?