Ответ 1
В VS - свойствах проекта - на вкладке Build - платформа target = X86
Я разработал службу Windows с помощью С#.NET для создания отчета в формате PDF. Для создания файла PDF я использую стороннюю DLL. Приложение работает на моей платформе Windows XP. Когда я развернул службу в Windows Server 2008 64-битной версии, я получил эту ошибку:
Получение класса COM factory для компонент с CLSID {46521B1F-0A5B-4871-A4C2-FD5C9276F4C6} не удалось из-за следующей ошибки: 80040154.
Я зарегистрировал DLL, используя команду regsvr32. Я могу видеть этот CLSID в реестре. Но проблема сохраняется.
В чем может быть проблема?
В VS - свойствах проекта - на вкладке Build - платформа target = X86
Похоже, что ваша служба была построена против "Any CPU", вызывая ошибки на 64-битных, когда вы используете COM-компоненты. Вам нужно построить его для x86
.
Веб-сайт, вероятно, работает как 32-разрядный процесс, поэтому он может использовать этот компонент. Построение вашего решения с помощью x86
заставит ваш сервис работать как 32-разрядный.
У меня возникла очень похожая проблема.
Мне нужно было использовать старую 32-разрядную DLL в веб-приложении, которое разрабатывалось на 64-битной машине. Я зарегистрировал 32-битную DLL в папку windows\sysWOW64, используя версию regsrv32 в этой папке.
Звонки в стороннюю DLL работали с модульных тестов в Visual Studio, но не с веб-приложения, размещенного в IIS, на том же компьютере с ошибкой 80040154.
Изменение пула приложений на "Включить 32-разрядные приложения" разрешило проблему.
Проблема заключается в том, что серверный процесс составляет 64 бит, а библиотека 32-разрядная и пытается создать COM-компонент в том же процессе (внутрипроцессного сервера). Либо вы перекомпилируете сервер и сделаете его 32-разрядным, либо оставите сервер без изменений и внесите COM-компонент вне процесса. Самый простой способ сделать COM-сервер вне процесса - создать приложение COM + - Панель управления → Администрирование → Компонентные службы.
Если вы ищете способ сделать эту работу без перекомпиляции своего приложения с любым процессором, вот еще одно потенциальное обходное решение:
Я не беру на себя ответственность за решение, но это сработало для нас. Проверьте ссылку источника для получения дополнительной информации и других комментариев.
Источник: https://techtalk.gfi.com/32bit-object-64bit-environment/
Вам не нужно настраивать целевую платформу X86 для платформы проекта. Вы также можете настроить параметры iis для работы с x86, как это
Я не изменял никаких параметров компиляции.
Просто установите "Включить 32-разрядное приложение = True" в дополнительных настройках AppPool.
Это сработало для меня
Решение для сервера Windows Server x64:
Эта процедура действительна, это нормально.
Имел связанную проблему с другим, но похожим исправлением:
У меня был проект службы Windows, установленный на "Any-CPU" с использованием 64-разрядной библиотеки DLL. Такое же сообщение об ошибке. Пробовал целую кучу вещей, но ничего не получилось. Наконец, я вошел в проект Properties → Build и заметил, что проект имел "Предпочитаю 32-бит". Непроверено это и больше ошибок.
Я предполагаю, что служба Windows ожидала 32-разрядную DLL и не могла ее найти.
У меня была такая же проблема, но в других ответах была предоставлена только одна часть решения.
Решение в два раза:
Извлеките 64-разрядный из регистра.
или
Зарегистрируйте его как 32bit:
C:\Windows\SysWOW64\regsvr32 <file.dll>
Регистрация его как 32-битной без удаления 64-битной регистрации не решит мою проблему.
Чтобы перейти на x86:
Если вы используете веб-сайт, вы также можете попытаться настроить пул приложений на запрещение 32-разрядных приложений (в дополнительных настройках пула).
Для тех, кто использует VSTO, проблема для меня была отсутствующей ссылкой на сборку office
. Это также проявляется, если вы пытаетесь создать экземпляр определенных объектов VSTO вручную.
В моем личном случае проблема была исправлена, ища идентификатор класса в реестре Windows на машине разработчика (потому что проблема была брошена на клиентский ПК). Это действие будет помещено в COM-компонент, который вызывает проблему: библиотека x86, на которую ссылается в моем проекте .NET, который не был зарегистрирован как OCX/COM для приложения-установщика или обновления.
Привет
Моя проблема заключалась в том, что у меня была неправильная версия MS Sync FrameWork (1.0) в моем проекте "Ссылки". После обновления до версии 2.1 ошибка исчезла, и жизнь снова стала хорошей.
Я обнаружил, что моя проблема связана с фактической регистрацией DLL.
Сначала запустите "Regedit.exe" из приглашения CMD (я поднял его уровень безопасности до "Администратор", на всякий случай "), затем выполните поиск в реестре (нажав" Изменить/найти "в меню RegEdit или нажав Ctrl + F) для CLSID, отображаемого в сообщении об ошибке, которое вы получили относительно фабрики COM-класса. Мой CLSID был 29AB7A12-B531-450E-8F7A-EA94C2F3C05F. Когда этот ключ найден, выберите подменю "InProcServer2" под этим узлом Hive и проверьте имя файла DLL проблемы в правой рамке Regedit. в разделе "По умолчанию". Если этот файл находится в папке "C:\Windows\SysWow64" (например, C:\Windows\SysWow64\Redemption.dll), то важно, чтобы вы использовали файл "C:\Windows\SysWow64\RegSvr32.exe" для зарегистрируйте эту DLL из командной строки, а НЕ - файл по умолчанию "C:\Windows\System32\RegSvr32.exe". Поэтому я запустил приглашение CMD (в разделе "Административный уровень" (на всякий случай этот уровень необходим) и введите (в случае моей DLL): C:\Windows\SysWow64\RegSvr32.exe c:\Windows\SysWow64\Redemption.dll нажмите клавишу ввода. Закройте окно команд (через "Выход", затем перезагрузите компьютер (всегда используйте перезапуск вместо Close Down, затем запустите, поскольку (как ни странно) Restart выполняет тщательное закрытие и перезагрузку всего, тогда как "Shut down" и Power-Up перезагружают сохраненный кэш драйверов и другие значения (что может быть неисправно). вы регистрируете DLL в будущем, не забудьте использовать SysWow64 "RegSvr32.exe" для любой DLL, хранящейся в папке C:\Windows\SysWow64, и эта проблема c (если она вызвана я ncorrect registration) не должно повториться.