我用c#开发了一个Windows服务。生成PDF报告。要生成PDF文件，我使用第三方dll。应用程序在我的Windows XP平台上运行。当我在Windows Server 2008 64位版本中部署服务时，我得到了这个错误:
检索的COM类工厂 带有CLSID的组件 {46521 b1f - 0 a5b - 4871 - a4c2 fd5c9276f4c6} 由于以下错误导致失败: 80040154.
我使用regsvr32命令注册了DLL。我能够在注册表中看到这个CLSID。但问题依然存在。
有什么问题吗?
当前回答
听起来你的服务是针对“任何CPU”构建的，导致你在使用COM组件的64位上出现错误。您需要为x86构建它。
该网站可能作为一个32位进程运行，这就是为什么它可以使用该组件。基于x86构建解决方案将迫使您的服务以32位的方式运行。
其他回答
问题是服务器进程是64位的，而库是32位的，它试图在同一个进程(进程内服务器)中创建COM组件。要么重新编译服务器，使其成为32位，要么保持服务器不变，使COM组件处于进程外。使COM服务器脱离进程最简单的方法是创建一个COM+应用程序-控制面板->管理工具->组件服务。
windows 2008服务器x64的解决方案是:
以管理员权限打开cmd.exe。 将dll拷贝到C:\Windows\SysWOW64文件夹 从C:\Windows\SysWOW64运行regsvr32 验证dll在Windows注册表中。 如果你有一个使用dll的。exe x86, exe必须在x86模式下编译。 exe必须安装在C:\Program Files (x86)文件夹中。
这个程序是有效的，是可以的
我也遇到过类似的问题。
我需要在64位机器上开发的Web应用程序中使用旧的32位DLL。我将32位DLL注册到windows\sysWOW64文件夹中，使用该文件夹中的regsvr32版本。
对第三方DLL的调用在Visual Studio中的单元测试中正常工作，但在同一台机器上的IIS中托管的Web应用程序中失败，并出现80040154错误。
将应用程序池更改为“启用32位应用程序”解决了该问题。
在我个人的情况下，这个问题是固定的搜索类id在Windows的注册表上的开发机器(因为这个问题是抛出在客户端PC)。该操作将被放置到引起问题的COM组件中:我的. net项目中引用的x86库没有为安装程序或更新程序应用程序注册为OCX/COM。
问候
在我的情况下，我正在生成ms office文件，如word或excel，我运行Win+R并执行dcomcnfg，在DCOM配置中，除了选择office相关的名称项(如名称包含excel或word或office)，并打开属性，选择身份选项卡并选择交互式用户。作为这个答案，
我的错误消息显示CLSID {000209FF-0000-0000-C000-000000000046}，所以我必须尝试在DCOM配置中找到这个特定的CLSID，它确实存在，我选择它并遵循相同的步骤设置交互用户，然后它就工作了。
