Как решить класс исключения COM не зарегистрирован (исключение из HRESULT: 0x80040154 (REGDB E CLASSNOTREG))?

вы должны убедиться, что все ваши сборки компиляции для правильной архитектуры. Попробуйте изменить архитектуру для x86, если переустановка COM-компонента не работает.

также обратите внимание, что контекст класса при инициализации может создать это исключение. Если у вас есть объект, который закодирован как INPROC_SERVER, но вы пытаетесь CoCreateInstance как CLSCTX_LOCAL_SERVER, вы также получите эту ошибку.

необходимо убедиться, что объект зарегистрирован и CoCreateInstance создает экземпляр с правильным контекстом класса.

Если вы используете 64-разрядные компоненты COM в веб-приложении на IIS, убедитесь, что пул приложений настроен на запрещение 32-разрядных приложений ( включить 32-разрядные приложения: false дополнительные параметры)

моя проблема и решение

У меня есть 32-битная сторонняя dll, которую я установил в машине 2008 R2, которая является 64-битной.

У меня есть служба wcf, созданная в .NET 4.5 framework, которая вызывает 32-разрядную стороннюю dll для процесса. Теперь у меня есть свойство build, настроенное на целевой "любой" процессор и развернутое на 64-разрядной машине.

когда я попытался вызвать службу wcf, появилась ошибка " 80040154 класс не зарегистрирован (исключение из HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG"

теперь я использовал ProcMon.exe, чтобы проследить ком вопрос реестра и установлено, что процесс ищет запись в реестре в\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 и HKCR\Wow6432Node\CLSID.

Это может быть достигнуто путем настройки свойств проекта службы wcf на целевой компьютер " X86 "вместо " Any".

после развертывания версии " X86 " на сервере 2008 R2 возникла проблема "Система.BadImageFormatException: не удалось загрузить файл или сборку"

решение для этого badimageformatexception устанавливает "Enable32bitApplications" в "True" в свойствах IIS Apppool для правильного apppool.

Я получил его для работы, включив 32-битные приложения в расширенных настройках пула приложений. Щелкните правой кнопкой мыши на пуле приложений и выберите Дополнительные параметры - включить 32-разрядные приложения. Это может помочь кому-то там.

путем регистрации класса ( в частности, его CLSID) -- см. например здесь.

в моем случае

my platform Это x64

the Dll library(sdk) и redistributable package это x64

так

1. в обозревателе решений navigate to your project

2. открыть Properties

3. change the Platform target from AnyCPU to x64

способ, которым я решил эту проблему, состоял в том, чтобы зарегистрировать COM через regsvr32.

убедитесь, что COM, который вы вызываете, зарегистрирован.

мое приложение использовало xceedcry.dll и я не регистрировал его. Как только я зарегистрировал его, приложение работало нормально.

для меня, я должен был создать 64-битную конфигурацию сборки.

Я столкнулся с этой проблемой, вызывая сборку .Net из клиента C++ через COM. Оказывается, что одна из сборок, от которой зависела сборка .Net, не может быть найдена. Я некоторое время боролся, пытаясь понять, что не так с 1-й сборкой, но на самом деле это была одна из зависимостей 1-й сборки. Я получил две разные ошибки при вызове CoCreateInstance () из клиента C++. Первый был: REGDB_E_CLASSNOTREG класс не зарегистрирован И вторая попытка было: 0x80131040 : определение манифеста сборки расположены не соответствует ссылке на сборку.

поэтому убедитесь, что ссылки на вашу сборку присутствуют. Я обнаружил это, просмотрев 1-ю сборку с помощью dotPeek и заметив, что одна из ее ссылок отсутствует. Размещение правильной версии зависимости в папке разрешило обе ошибки.

Я компилировал свое приложение таргетинга любой ЦП и главная проблема оказалась в том, что adobe reader был установлен старше v10.x нужно обновлениеv11.x, это способ, как я получаю, чтобы решить эту проблему.

мое решение было изменить " Включить 32-Разрядные Приложения " значение True в дополнительных настройках относительного пула приложений в IIS.

я столкнулся с такой же проблемой через COM-класс, т. е. класс не зарегистрирован исключение во время выполнения. Для меня я смог решить, перейдя в приложение.конфигурационный файл и измените элементы "startup" и "supportedRuntime" на что-то вроде:

<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0"/>
  </startup>
</configuration>

вы можете прочитать больше о деталях здесь http://stackoverflow.com/questions/1604663/

а здесь https://msdn.microsoft.com/en-us/library/w4atty68 (v=vs. 110). aspx

I следует отметить, что я запускаю Visual Studio 2017. Целевой процессор = x86 Внедрить тип взаимодействия = true (в окне свойств)

в моем случае класс был зарегистрирован правильно и встроен в любой процессор / 64 бит режим.

но включить 32-разрядные приложения свойства пул приложений IIS приложения, которое использует класс был установлен в True.

класс не был найден из-за несоответствия архитектуры между конфигурацией пула приложений и фактическим зарегистрированным классом.

задание включить 32-разрядные приложения до False Исправлена проблема.

У меня была такая же проблема с использованием MapWinGis. Я нашел решение, работая над visual studio 2015 windows forms proyect, просто щелкните правой кнопкой мыши на proyect-> properties - > Build, установите конфигурацию для всех конфигураций и в conbobox "platform target" установите его на x64.

перейдите в каталог .Net framework и зарегистрируйте их соответствующую dll с помощью команду regsvr32.exe пустое пространство dll путь.

Я столкнулся с той же проблемой. После некоторых исследований я нашел исправление для меня, и это может быть полезно. Проблема не только связана с повторной установкой на момент моего наблюдения, она также зависит от разрешений доступа.

Шаг 1: восстановление конкретного объекта COM.

Шаг 2: службы компонентов > компьютеры > конфигурация DCOM > выберите свой COM-объект > щелкните правой кнопкой мыши > свойства > вкладка Безопасность > права доступа > выберите Настроить > нажмите кнопку Изменить > выберите IIS_USER (если не существует создать с полными правами) и дать полный доступ и нажмите кнопку ОК.

перейдите на вкладку идентификация > можно выбрать "интерактивный пользователь" или "пользователь" > Нажмите кнопку "Применить" и "ОК". Если вы выберете "этот пользователь", мы должны предоставить административному привилегированному пользователю этот сервер

Шаг 3: Откройте Диспетчер IIS > перезапустите пулы приложений.

Примечание: при необходимости перезагрузите сервер

здесь найти решение, запустите mmc -32 tool (не dcomcfg)

на 64-битной системе с 32-битным офисом попробуйте это:

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