C#
An object-oriented and type-safe programming language that has its roots in the C family of languages and includes support for component-oriented programming.
10,298 questions
Office Interop Excel error TYPE_E_CANTLOADLIBRARY with x64 64bit build
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(272, 28.000000000000004%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDN%3C/text%3E%3C/svg%3E)
developing now
1
Reputation point
Hi community,
My program fails on a different machine than my development machine. If I compile in x86 it works, but if I compile in x64 (which I have to) it fails.
The error:
When I call the Excel API from within my C# application, I get the following error:
System.InvalidCastException: Unable to cast COM object of type 'Microsoft.Office.Interop.Excel.ApplicationClass'
to interface type 'Microsoft.Office.Interop.Excel._Application'.
This operation failed because the QueryInterface call on the COM component for the interface
with IID '{000208D5-0000-0000-C000-000000000046}' failed due to the following error:
Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)).
at System.StubHelpers.StubHelpers.GetCOMIPFromRCW(Object objSrc, IntPtr pCPCMD, IntPtr& ppTarget, Boolean& pfNeedsRelease)
at Microsoft.Office.Interop.Excel.ApplicationClass.get_Workbooks()
when I call:
Excel.Application excelApplication = new Excel.Application();
Excel.Workbooks excelWorkBooks = excelApplication.Workbooks;
My dev machine:
Windows 10 Pro x64 21H2
Excel 2016 32 Bit installed
Visual Studio 2017
Build C# exe with target x64
The target machine:
Windows 10 Pro x64 21H2
Excel 2016 32 Bit installed
Fresh install, no other Office version was ever installed, machine is freshly setup
Disclaimer:
Please note that this is the error "TYPE_E_CANTLOADLIBRARY" and NOT the other error "TYPE_E_LIBNOTREGISTERED".
I have already spent a lot of time searching for related questions and I have checked my registry thoroughly. Especially this key is properly in the registry:
Computer\HKEY_CLASSES_ROOT\Interface{000208D5-0000-0000-C000-000000000046}\TypeLib
has the value: "{00020813-0000-0000-C000-000000000046}" with version = 1.9
The key:
Computer\HKEY_CLASSES_ROOT\TypeLib{00020813-0000-0000-C000-000000000046}\1.9\0
contains two children: "win32" and "Win64" both with the value: "C:\Program Files (x86)\Microsoft Office\Office16\EXCEL.EXE"
And I checked, that .exe file exists at that location.
Clarification
- It works if I build my program with target x86 but fails on the same target machine if I build with target x64.
- For unrelated reasons, I am forced to deploy my program exclusively as a x64 only.
- It always works either way no matter the build on my dev machine.
- It has to work reliably out of the box, since the target machine is a customer machine, actions such as "Re-install Office" are not a valid solution. I have no control over the target machine.
- I could modify the target machine's registry through my installer and I could also deploy any dlls if that would solve the problem.
I hope someone can help me!
See you!
C#
{count} votes
-
RLWA32 40,771 Reputation points2022-06-13T13:41:45.3+00:00 The key:
Computer\HKEY_CLASSES_ROOT\TypeLib{00020813-0000-0000-C000-000000000046}\1.9\0
contains two children: "win32" and "Win64" both with the value: "C:\Program Files (x86)\Microsoft Office\Office16\EXCEL.EXE"Does this same situation exist on both your development system where both 32 and 64 bit builds run successfully and the target system where the 64 bit build fails?
-
Jack J Jun 24,296 Reputation points Microsoft Vendor2022-06-14T07:53:35.287+00:00 @developing now ,Welcome to Microsoft Q&A, based on my test, I could run the code without the exception when it is build as x64. How do you call the Excel API? There are two methods to call the Excel API. One is to add nuget-package
Microsoft.Office.Interop.Exceland the other is to add COM referenceMicrosoft Excel 16.0 Object Library. I recommend that you could choose another method to call the excel api to check if it works for you. -
developing now 1 Reputation point
2022-06-22T08:02:35.81+00:00 Thanks for the comments. I did some more testing with the registry.
So initially (before I started messing with the registry) on my dev machine, there existed only the win32 key. On the target machine, there existed the win32 key with a correct file path (C:\Program Files (x86)\Microsoft Office\Office16\EXCEL.EXE) and also the Win64 key with a bad path pointing at a nonexistent file (C:\Program Files\Microsoft Office\Root\Office16\EXCEL.EXE).On my dev machine, it works with any constellation, both keys (win32 and Win64) existing or only one of them, doesn't matter as long as the path is set correctly.
Now this is interesting: On the target machine, my x64 build always fails, with the same error message, no matter which keys are there. BUT when I run my x86 build something happened: When only the win32 key exists or both keys exists, it simply runs and works. But when only the Win64 key exists, upon starting my program a popup from Office came on, telling me "Configuring Office". After a couple of seconds it disappeared and when I checked the registry afterwards, the win32 key had been added automatically!Another observation: On the target machine, many broken registry keys named "Win64" exist in other places which all point to that none nonexistent path like above.
@Jack J Jun :
I am using the COM reference method. I have yet to try with a nuget-package. -
RLWA32 40,771 Reputation points
2022-06-22T11:01:26.737+00:00 Well, it looks like your target machine had a different version of Office installed at one time or another. You might want to try repairing the Office installation.
Sign in to comment