Як вирішити клас винятків 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 framework, яка викликає 32-бітну сторонній dll для процесу. Тепер у мене є властивість build, націлене на "будь-який" процесор, і розгорнув його на 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 Apppool для правильного пулу додатків.

Також зауважте, що контекст класу при ініціалізації може створити цей виняток. Якщо у вас є об'єкт, кодований як 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-розрядні програми " на True у розширених налаштуваннях відносного пулу додатків у IIS.

У моєму випадку клас був зареєстрований належним чином і побудований у БУДЬ-ЯКОМ ЦП / 64-бітному режимі.

Але властивість Enable 32-bit Applications Applications пулу додатків IIS програми, яка використовує клас, було встановлено на True .

Клас не знайдено через невідповідність архітектури між конфігурацією пулу програм та фактичним зареєстрованим класом.

Налаштування Увімкнути 32-розрядні програми на False вирішило проблему.

Для мене мені довелося створити 64-бітну конфігурацію збірки.

У мене була та ж проблема з використанням MapWinGis. Я знайшов рішення, працюючи на Visual Studio 2015 windows form proyect, просто клацніть правою кнопкою миші на proyect-> Properties-> Build, встановіть конфігурацію на Усі конфігурації, а в консоні "ціль платформи" встановіть на x64.

Я зіткнувся з цією проблемою, викликаючи збірку .Net із клієнта C ++ через COM. Виявляється, одну із збірок, від якої залежала збірка .Net, не вдалося знайти. Я деякий час боровся, намагаючись зрозуміти, що не так з 1-м збором, але насправді це було однією із залежностей 1-го зібрання. Я отримав дві різні помилки під час виклику CoCreateInstance () від клієнта С ++. Перший був: Клас REGDB_E_CLASSNOTREG не зареєстрований . Другий спробою був: 0x80131040: Визначення маніфесту розташованої збірки не відповідає посиланню на збірку.

Тож перевірте, чи є посилання на вашу збірку. Я виявив це, переглянувши 1-ю збірку за допомогою 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. Ціль cpu = x86 Embed Interop Type = true (у вікні властивостей)

перейдіть до каталогу фреймворка .Net та зареєструйте відповідну dll за допомогою dgs шляху Regsvr32.exe .

Я стикався з тим самим питанням. Після деяких досліджень я знайшов виправлення для мене, і це може бути корисно. Проблема пов’язана не лише з перевстановленням, на моє спостереження, це також залежить від дозволів на доступ.

Крок 1: Відремонтуйте конкретний COM-об'єкт.

Крок 2: Служби компонентів> Комп'ютери> Мій комп'ютер> Конфігурація DCOM> Виберіть COM-об'єкт> Клацніть правою кнопкою миші> Властивості> Вкладка Безпека> Дозволи доступу> Виберіть Налаштувати> Клацніть РЕДАКТУВАТИ> Виберіть IIS_USER (якщо не існує, створіть із повними правами) і надайте доступ та натисніть OK.

Перейдіть на вкладку «Особистість»> Ви можете вибрати «Інтерактивний користувач» або «Цей користувач»> Клацнути Застосувати та ОК. Якщо ви виберете "Цей користувач", ми повинні надати адміністратору привілейованого користувача цьому серверу

Крок 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