Когда я пытаюсь создать экземпляр класса COM, он выдает исключение как
Класс не зарегистрирован (Исключение из HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
Пожалуйста, предложите, как я мог решить это?
Вам необходимо убедиться, что все ваши сборки компилируются для правильной архитектуры. Попробуйте изменить архитектуру для x86, если переустановка компонента COM не работает.
Похоже, что какая бы программа или процесс, который вы пытаетесь инициализировать, либо не установлен на вашем компьютере, имеет поврежденную установку или нуждается в регистрации.
Либо установите его, отремонтируйте его (через программы добавления / удаления), либо зарегистрируйте его (через Regsvr32.exe).
Вы не предоставили нам достаточно информации, чтобы помочь вам больше, чем это.
Моя проблема и решение
У меня есть 32-битный сторонний dll, который я установил на машине R2 2008 года, которая составляет 64 бита.
У меня есть служба wcf, созданная в среде .net 4.5, которая вызывает 32-битный сторонний dll для процесса. Теперь у меня есть свойство сборки, установленное для цели 'any' cpu, и развернуто на 64-битной машине.
когда я попытался вызвать службу wcf, возникла ошибка "80040154 Класс не зарегистрирован (Исключение из HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG")
Теперь я использовал ProcMon.exe для отслеживания проблемы с реестром com и обнаружил, что процесс ищет запись реестра в HKLM \ CLSID и HKCR \ CLSID, где нет записи.
Стало известно, что Microsoft не будет регистрировать 32-битные компоненты com на пути HKLM \ CLSID, HKCR \ CLSID на 64-битном компьютере, а не помещает запись в пути HKLM \ Wow6432Node \ CLSID и HKCR \ Wow6432Node \ CLSID.
Теперь конфликт представляет собой 64-битный процесс, пытающийся вызвать 32-битный процесс на 64-битном компьютере, который будет искать запись реестра в HKLM \ CLSID, HKCR \ CLSID. Решение состоит в том, что мы должны заставить 64-битный процесс просматривать запись реестра в HKLM \ Wow6432Node \ CLSID .
Этого можно достичь, настроив свойства сервисного проекта wcf на машину «X86» вместо «Any».
После развертывания версии 'X86' на сервере R2 2008 года возникла проблема "System.BadImageFormatException: не удалось загрузить файл или сборку"
Решением этой badimageformatexception является установка «Enable32bitApplications» в «True» в свойствах IIS Apppool для правильного пула приложений.
Также обратите внимание, что контекст класса при инициализации может создать это исключение. Если у вас есть объект, который закодирован как INPROC_SERVER, но вы пытаетесь CoCreateInstance как CLSCTX_LOCAL_SERVER, вы также получите эту ошибку.
Вам необходимо убедиться, что объект зарегистрирован, а CoCreateInstance создает экземпляр с правильным контекстом класса.
Если вы используете 64-битные компоненты COM в веб-приложении на IIS, убедитесь, что в пуле приложений не разрешено использование 32-битных приложений ( Включить 32-битные приложения: false в расширенных настройках)
Я начал работать с включением 32-битных приложений в расширенные настройки пула приложений. Щелкните правой кнопкой мыши пул приложений и выберите расширенные настройки - включите 32-битные приложения. Это может помочь кому-то там.
Регистрируя класс (в частности, его CLSID) - см., Например,. [здесь][1].
[1]: http://msdn.microsoft.com/en-us/library/ms678406 (VS.85).aspx
в моем случае
«Моя платформа» - это x64
Библиотека Dll (sdk)
и перераспределяемый пакет
- x64
так
в поиске решений «перейти к вашему проекту»
открыть «Свойства»
изменить цель платформы с AnyCPU на x64
Я решил эту проблему, чтобы зарегистрировать «COM» через «regsvr32».
убедитесь, что вызываемый вами COM зарегистрирован.
Мое приложение использовало xceedcry.dll
, и я не регистрировал его. Как только я зарегистрировал его, приложение работало нормально.
У меня была такая же проблема с использованием MapWinGis. Я нашел решение, работая над визуальной студией 2015 Windows формирует проект, просто щелкните правой кнопкой мыши на proyect- > свойства- > Сборка, настройка конфигурации для всех конфигураций и в «платформенной цели» conbobox установите для нее x64.
Я столкнулся с той же проблемой. После некоторых исследований я нашел исправление для меня, и это может быть полезно. Проблема связана не только с переустановкой, насколько я понимаю, она также зависит от прав доступа.
Шаг 1: Восстановите конкретный объект COM.
Шаг 2: Услуги компонентов > Компьютеры > Мой компьютер > Конфигурация DCOM > Выберите свой COM-объект > Щелкните правой кнопкой мыши > Свойства > Вкладка безопасности > Разрешения на доступ > Выберите Настроить > Нажмите РЕДАКТИРОВАТЬ > Выберите IIS_USER (Если не существует, создайте с полными правами) и дать полный доступ и нажать ОК . Перейдите на вкладку «Идентичность» > Вы можете выбрать «Интерактивный пользователь» или «Этот пользователь» > Нажмите Применить и ОК. Если вы выберете «Этот пользователь», мы должны предоставить административно привилегированного пользователя этому серверу
Шаг 3: Откройте IIS Manager > Перезапустите пулы приложений.
Примечание. При необходимости перезагрузите сервер
Я столкнулся с этой проблемой, вызвав сборку .Net от клиента C ++ через COM. Оказывается, одну из сборок, от которых зависела сборка .Net, найти не удалось. Некоторое время я боролся, пытаясь выяснить, что не так с 1-м собранием, но на самом деле это была одна из зависимостей 1-го собрания. Я получил две разные ошибки при вызове CoCreateInstance () из клиента C ++. Первым был:
Так что убедитесь, что ссылки вашей сборки присутствуют. Я обнаружил это, просмотрев 1-ю сборку с помощью dotPeek и заметив, что одна из его ссылок отсутствует. Размещение правильной версии зависимости в папке позволило устранить обе ошибки.
Я компилировал свой целевой файл приложения для любого процессора , и основная проблема заключалась в том, что считыватель Adobe был установлен старше v10.x необходимо обновить v11.x , так я могу решить эту проблему.
Я столкнулся с той же проблемой, используя класс COM, т.е. «Класс не зарегистрированный исключение» во время выполнения. Для меня я смог решить, перейдя в файл app.config и изменив элементы «startup» и «supportedRuntime» на что-то вроде:
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
Вы можете прочитать больше о деталях здесь [https://stackoverflow.com/questions/1604663/][1]
и здесь [https://msdn.microsoft.com/en-us/library/w4atty68 (v = vs.110).aspx][1]
[1]: https://msdn.microsoft.com/en-us/library/w4atty68 (v = vs.110).aspx
Следует отметить, что я работаю в Visual Studio 2017. Цель cpu = x86 Вставить тип Interop = true (в окне свойств)
В моем случае класс был зарегистрирован должным образом и встроен в режим ANY CPU / 64 бит .
Но свойство Включить 32-разрядные приложения в пуле приложений IIS приложения, использующего класс, было установлено в True .
Класс не был найден из-за несоответствия архитектуры между конфигурацией пула приложений и фактическим зарегистрированным классом.
Настройка Включить 32-битные приложения в False исправила проблему.
перейдите в каталог .Net framework и зарегистрируйте их соответствующий dll с помощью Regsvr32.exe пробела dll path.
Здесь найдите решение, запустите инструмент mmc -32 (не dcomcfg)
В 64-битной системе с 32-битным Office попробуйте это:
Start
Run
mmc -32
File
Add Remove Snap-in
Component Services
Add
OK
Console Root
Component Services
Computers
My Computer
DCOM Config
Microsoft Excel Application