无法将“microsoft.Office.Interop.Excel.ApplicationClass”类型的 COM 对象转换为“microsoft.Office.Interop.Excel.Application””

Question

This is my first attempt to capture some data from excel from within one C# console application.

I get the error "unable to cast COM object of type 'microsoft.Office.Interop.Excel.ApplicationClass' to 'microsoft.Office.Interop.Excel.Application'".

This code used the 'Microsoft Excel 12.0 Object Library' , and I gave reference to Microsoft.Office.Interop.Excel.

Still, I could not get over this error - which I believe has its own quick solution.

I digged a little bit this site and came across with this solution: Interop type cannot be embedded

However, I could not understand so could not implement what was suggested as a solution.

My .Net version is 4.5.

Any help is very much appreciated.

Thanks in advance.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;

using Excel = Microsoft.Office.Interop.Excel;

namespace deneme
{
class Program
{
    static void Main(string[] args)
    {

        Excel.Application xlApp = new Excel.Application();
        xlApp.Visible = true; // <-- excel application
        xlApp.DisplayAlerts = false;

        // Open the workbook.
        Excel.Workbook wBook = xlApp.Workbooks.Open("C:\\FNN\\XLA\\fnnComTemplate.xlsx",
            Type.Missing, Type.Missing, Type.Missing, Type.Missing,
            Type.Missing, Type.Missing, Type.Missing, Type.Missing,
            Type.Missing, Type.Missing, Type.Missing, Type.Missing,
            Type.Missing, Type.Missing);

        // get the sheet
        Excel.Worksheet wSheet = wBook.Sheets[0];
        // foreach (Excel.Worksheet sheet in wBook.Sheets) { if (sheet.Name == "templateSheet") { wSheet = sheet; } }

        Excel.Range rng = wSheet.get_Range("A1");

        aux = wSheet.Range["F6"].Value;

        Console.WriteLine("interop result:" + aux);
        Console.ReadLine();

    }

}
}

Answer 1

Microsoft Office 365

I was running Microsoft Office 365 with Windows 10 and tried the mentioned solutions to remove the registry key without success.

I went to the control panel in an attempt to repair the Office 365 suite.

1. Right Click on Start Menu
2. Click Apps and Features
3. Search Microsoft 365
4. Click Microsoft 365
5. Click Modify

I selected the quick repair

Tried my program again and everything worked!

Answer 2

If this is not a code related error than please remove below given key from registry.

Steps:

Start--> Run --> regedit --> HKEY_CLASSES_ROOT-->TypeLib-->{00020813-0000-0000-C000-000000000046} --> 1.8/1.7 (Delete this)

Solution: This issue can be resolved by deleting an invalid registry key left over from the higher version of Office. Follow the above steps.

Cause: This issue is caused by a left over registry key if you have downgraded your version of Microsoft Office from either Office 2010 to Office 2007, or Office 2013 to Office 2010 or 2007.

Let me know if this solution is not helped to you

Answer 3

I am sure the answers to this question (and similar questions) proposing editing the registry and removing old references to versions of Office no longer on the machine are correct .

I am only adding this answer because I am currently kicking myself. Two hours spent hunting keys in the registry and getting nowhere. Last throw of the dice was to try a simple repair on Microsoft Office and suddenly my error is gone.

... seems to me it's worth trying a repair before getting too deep into manually editing the registry.

Answer 4

Windows 7 x64 / Office 365 (16.0.x) 32-bit / VS 2019

Was checked Registry ->HKEY_CLASSES_ROOT->TypeLib, look for {00020813-0000-0000-C000-000000000046} exist only one record "1.9", nothing else.

Checking problem by Process Monitor detecting possible problem with finding and reading from vbe6ext.olb (many results with "NAME NOT FOUND").

Was made "Quick Repair" from Repair Office from the Control Panel , after that problem is gone.

PS> Was made checking "after treatment" by Process Monitor - now file VBE6EXT.OLB are taking from C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\VBA\VBA6\ by first probe.

Answer 5

In my case I delete regedit in:

HKEY_CLASSES_ROOT\TypeLib\{00020813-0000-0000-C000-000000000046}

delete 1.9

and problem solved.

Answer 6

A machine had been updated to Office 2016 64-bit and the COM interface was throwing exceptions when called from the a 32-bit application. It did not have old TypeLib entries like the ones in Jayesh's answer.

Comparing ProcessMonitor traces to a working machine with Office 2016 led to what look like dead end registry keys in

HKEY_CLASSES_ROOT\Wow6432Node\TypeLib\{00024..

The working machine would check for the non-existent registry key and return

NAME NOT FOUND

The failing machine had the registry key but then would throw an exception shortly thereafter.

After repeatedly deleting the registry key, rerunning the trace, deleting the next failing key, the COM interface functionality was restored.

Answer 7

Had both 1.7 and 1.8 in registry. Resolved by removing:

HKEY_CLASSES_ROOT\TypeLib\{00020813-0000-0000-C000-000000000046}\1.8

Answer 8

Repair Office did not work for me. I did a full repair but still the problem is there.

This worked for me:

Start--> Run --> regedit --> HKEY_CLASSES_ROOT-->TypeLib-->{00020813-0000-0000-C000-000000000046} --> 1.8/1.7 (Delete the entire node)

Office will auto repair when you invoke from Visual Studio your Interop App.

My situation is I installed Office 2016 but only a trial version. I removed it and switched back to Office 2013.

After that, this problem occurred. The deletion of the key prompted an Auto Repair of Office 2013 that solved my problem.

Answer 9

I had this issue in PowerShell. Along with the mentioned issue, $xlApp.Workbooks returned null for me. Running the PowerShell script in 32-bit mode resolved my issue.

Answer 10

Using the exact same code I got the same problem in a laptop when everything worked fine on another one. I tried various solutions found here and there in the internet but what finally worked, was the explicit definition of the use of non 32 bit version of the library. For doing so in visual studio, I had to tick and then untick the box "Prefer 32-bit" in the build section of the project configuration, which added <Prefer32Bit>false</Prefer32Bit> in the .csproj file.

Answer 11

For whatever reason, my Script just stopped working one day.

Running Powershell in 32-bit mode like here circumvented my issue.

Answer 12

Nothing worked for me so I removed Office 32-bit and installed the 64-bit version; The Error went away.

Answer 13

My setup: Visual Studio: 2019, Office: 2019 x64, Target Framework: net5.0-windows

Nothing help me from error: Unable to cast COM object of type 'System.__ComObject' 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. (0x80029C4A (TYPE_E_CANTLOADLIBRARY)). Unable to cast COM object of type 'System.__ComObject' 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. (0x80029C4A (TYPE_E_CANTLOADLIBRARY)).

So I found via Sysinternals Process Monitor missed file path for Excel.exe at Registry for Win32 and changed it to existing x64 vesion:

[HKEY_CLASSES_ROOT\TypeLib\{00020813-0000-0000-C000-000000000046}\1.9\0\win32]
@="C:\\Program Files\\Microsoft Office\\Root\\Office16\\EXCEL.EXE"

Answer 14

Repairing my Office 2016 did not work and my registry looked fine (1.9 only) but I noticed a couple of the solutions here mentioned 64 and 32 bit versions of office and it made me wonder about how I was compiling my (VB Net) program. My Office is 32 bit but my Windows is 64 bit and I was using the "Any CPU" configuration in Visual Studio (2019). Changing this to the x86 configuration and recompiling solved the problem.