Class not registered error when creating Excel workbook in C#

Question

When I try to access an Excel spreadsheet using the following code I get a \"Library not registered\' error when defining the workbook object wrkbuk using C# from Visual Studio

Answer 1

Had the same problem... The code that was previously running, started throwing the same exception when a new Application instance was created. To fix this:

1. Programs and Features, did an order by date installed and could see there were some Microsoft Office 365 updates from the same day the code had stopped working.
2. For both Microsoft Office 365 -en-us and Microsoft Office 365 Pro Plus -en-us, right click Change and select Quick Fix

Tried to run my solution and it was working again.

Answer 2

I had this exact same problem. Here's how I fixed it:

Go to

HKEY_CLASSES_ROOT\TypeLib\ and search for Office.Interop.Excel.

I found HKEY_CLASSES_ROOT\TypeLib\(guid)\1.8 but its child nodes were empty! I deleted it because Office 15 wasn't installed on that machine, and hey presto - it worked.

Either our VSTO project installer, or our own custom installer must have placed the 1.8 folder there.

I found the solution here:

Error accessing COM components

Answer 3

I will confirm @stuzor 's answer on two machines I've encountered.

Background:

Windows7 64 bit
Office 2010 (32bit) 
Lync 2013 

HKEY_CLASSES_ROOT\TypeLib\ , searched for "Office.Interop.Excel". Found the barely existent "1.8" folder. Upon deletion, the function in an old VB.net app began working immediately.

Answer 4

I had exactly the same issue. If you have installed a new version of Office and for some reason you have to install the older version without removing the new one (For my case I just need to install the Office XP Photo Editor) and this caused the issue.

After spending 3 hours up and down, the best way is to repair the new version of Office and everything was back to normal as it should be.

Hope this info helps provided you have the same or similar scenario.

Answer 5

This is an answer if you can not modify or delete the regedit records. I had the same problem, in the company where I work, there are about 30 machines with office 2010 and I could not erase or open records in the regedit. because the client machine was in a domain that would not let me. although I had administrator permissions it did not allow me to delete records in the regedit. I tried to find a solution for 1 month, and I did not find it. so I had to stop using interop and migrate to OpenXml to edit excel templates and ClosedXml to create new excel. This saved my life, because my boss was already pressing me.

Open the project/solution in Visual Studio, and open the console using the Tools > NuGet Package Manager > Package Manager Console command. and install 2 packages

1. Install-Package DocumentFormat.OpenXml -Version 2.5.0
2. Install-Package SpreadsheetLight

pd: OpenXml 2.8 dont work with SpreadsheetLight, better use 2.5.0

add this in the beggining

using DocumentFormat.OpenXml;
using DocumentFormat.OpenXml.Packaging;
using DocumentFormat.OpenXml.Spreadsheet;
using SpreadsheetLight;

in your button or class copy and modify

    SaveFileDialog fichero = new SaveFileDialog();
    fichero.Filter = "Excel (*.xlsx)|*.xlsx";
    if (fichero.ShowDialog() == DialogResult.OK)
    {
        SLDocument sl = new SLDocument("c:\\bin\\est1.xlsx", "Sheet1");

        sl.SetCellValue("E9", "Let's party!!!!111!!!1");

        sl.SelectWorksheet("Sheet2");
        sl.SetCellValue("C7", "Before anyone calls the popo!");

        sl.AddWorksheet("ERTRT");
        sl.SetCellValue("B4", "Who let the dogs out?");
        sl.SetCellValue("B5", "Woof!");

        sl.SaveAs(fichero.FileName);    

        MessageBox.Show("Report " + fichero.FileName + "!");
    }

Answer 6

Something which hasn't been mentioned here but which may be useful is that subkeys of 1.XX can cause issues as well. For example: Under Computer\HKEY_CLASSES_ROOT\TypeLib{00020813-0000-0000-C000-000000000046} I had the subkey 1.9. This in turn has the subkey 0(or should). Now under this, there were two subkeys - Win32 and Win64. As a result, Visual Studio was unable to resolve the location of Microsoft.Office.Interop.Excel.dll - it was reading two subkeys where it could only read one. Deleting the Win32 subkey fixed my issue completely. Please note that this was done after a complete reinstall of VS 2017 & Office 365 Pro Plus. Hope this helps someone.