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

Когда я пытаюсь создать экземпляр класса COM, он выдает исключение как

Класс не зарегистрирован (исключение из HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))

Пожалуйста, предложите, как я могу это решить?

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

Либо установите, либо отремонтируйте (с помощью «Установка и удаление программ»), либо зарегистрируйте (с помощью Regsvr32.exe).

Вы не предоставили нам достаточно информации, чтобы помочь вам, кроме этой.

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

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

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

У меня есть служба wcf, созданная в платформе .net 4.5, которая вызывает 32-битную стороннюю dll для процесса. Теперь у меня есть свойство сборки, настроенное на «любой» процессор, и я развернул его на 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 и HKCR \ Wow6432Node \ CLSID.

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

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

Решением этого badimageformatexception является установка для Enable32bitApplications значения True в свойствах пула приложений IIS для правильного пула приложений.

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

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

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

Я заставил его работать, включив 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а я его не регистрировал. Как только я зарегистрировал его, приложение заработало нормально.

Мое решение состояло в том, чтобы изменить « Включить 32-разрядные приложения » на «Истина» в дополнительных настройках относительного пула приложений в IIS.

В моем случае класс был зарегистрирован правильно и построен в ЛЮБОМ ЦП / 64-битном режиме.

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

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

Установка параметра « Включить 32-разрядные приложения» в значение « Ложь» устранила проблему.

Мне пришлось создать 64-битную конфигурацию сборки.

У меня была такая же проблема с использованием MapWinGis. Я нашел решение, работая над проектом Windows Forms Visual Studio 2015, просто щелкните правой кнопкой мыши proyect-> properties-> Build, установите конфигурацию на All configurations, а в conbobox «target platform» установите его на x64.

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

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

Я компилировал свое приложение, нацеленное на любой процессор, и основная проблема оказалась в том, что был установлен Adobe Reader, более старый v10.x необходимо обновить v11.x , вот как я могу решить эту проблему.

Я столкнулся с той же проблемой, используя класс COM, то есть «исключение класса не зарегистрировано» во время выполнения. Мне удалось решить эту проблему, перейдя в файл app.config и изменив элементы «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

Следует отметить, что я запускаю Visual Studio 2017. Target cpu = x86 Embed Interop Type = true (в окне свойств)

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

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

Шаг 1. Восстановите конкретный COM-объект.

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

Перейдите на вкладку «Удостоверение»> Вы можете выбрать «Интерактивный пользователь» или «Этот пользователь»> Нажмите «Применить» и «ОК». Если вы выберете «Этот пользователь», мы должны предоставить этому серверу пользователя с правами администратора.

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

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

Здесь найдите решение, запустите инструмент 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