I developed a Windows service using C#.NET to generate PDF report. To generate PDF file I am using a third party dll. The application is running in my Windows XP platform. When I deployed the service in Windows Server 2008 64 bit version, I got this error:
Retrieving the COM class factory for component with CLSID {46521B1F-0A5B-4871-A4C2-FD5C9276F4C6} failed due to the following error: 80040154.
I registered the DLL using the regsvr32 command. I able to see this CLSID in the registry. But the problem persists.
What could be the problem?
This question is related to
.net
windows-services
com-interop
32bit-64bit
The problem is that the server process is 64 bit and the library is 32-bit and it tries to create the COM component in the same process (in-proc server). Either you recompile the server and make it 32-bit or you leave the server unchanged and make the COM component out-of-process. The easiest way to make a COM server out-of-process is to create a COM+ application - Control Panel -> Administrative Tools -> ComponentServices.
My problem was that I had the wrong MS Sync FrameWork version (1.0) in my project References. After update to the version 2.1, the error was gone and life is good again.
If you are running a website, you could also try to set your application pool to disable 32-bit Applications (under advanced settings of a pool).
Had a related issue with a different, but similar fix:
I had a Windows service project set to "Any-CPU" using a 64-bit DLL. Same error message. Tried a whole bunch of things, but nothing worked. Finally, I went into project Properties -> Build and noticed that project had "Prefer 32-bit" checked. Unchecked this and no more error.
My guess is that the windows service was expecting a 32-bit DLL, and couldn't find it.
I found that my problem related to the actual registration of the DLL.
The solution for windows 2008 server x64 is:
This procedure is valid, it is ok.
To change to x86:
I ran into a very similar issue.
I needed to use an old 32-bit DLL within a Web Application that was being developed on a 64-bit machine. I registered the 32-bit DLL into the windows\sysWOW64 folder using the version of regsrv32 in that folder.
Calls to the third party DLL worked from unit tests in Visual Studio but failed from the Web Application hosted in IIS on the same machine with the 80040154 error.
Changing the application pool to "Enable 32-Bit Applications" resolved the issue.
If you are looking for a way to make this work without recompiling your Any CPU application, here is another potential workaround:
I take no credit for the solution, but it worked for us. Check the source link for more information and other comments.
Source: https://techtalk.gfi.com/32bit-object-64bit-environment/
I didn't change any compile settings.
Just set "Enable 32-bit Application = True" in AppPool Advanced Settings.
It worked for me
You dont have to configure your project properties platform target X86. You can also configure the iis options to work with x86 like that
In my case, I'm producing ms office file like word
or excel
, I run Win+R
and execute dcomcnfg
, in the DCOM Config, besides select OFFICE related name item (such as name contains Excel
or Word
or Office
) and Open the properties, select Identity tab and select the interactive user.
as this answer,
My error message show CLSID {000209FF-0000-0000-C000-000000000046}
, so I have to try to find this specific CLSID in DCOM Config, and it does exsits, and I select it and follow same step set the interactive user
, then it works.
For anyone using VSTO, the problem for me was a missing reference to the office
assembly. It would also appear if you were trying to instantiate certain VSTO objects manually.
It sounds like your service was built against 'Any CPU', causing you errors on 64-bit where you are using COM components. You need to build it for x86
.
The website is probably running as a 32-bit process which is why it can use the component. Building your solution against x86
will force your service to run as 32-bit.
In my personal case the issue was fixed searching for the class id in the Windows's Registry on developer machine (because the issue was thrown in a client PC). This action will be placed into the COM component that causes the issue: an x86 library referenced in my .NET project that was not being registered as OCX/COM for the installer or updater application.
Regards
I had the same issue, but the other answers only supplied one part of the solution.
The solution is two fold:
Remove the 64bit from the Register.
or
Register it as 32bit:
C:\Windows\SysWOW64\regsvr32 <file.dll>
Registering it as 32bit without removing the 64bit registration does not resolve my issue.
Source: Stackoverflow.com