BUG: “Old format or invalid type library” error when automating Excel (Christin Boyd)

  • Comments 7

A customer recently reported this bug when running their Shared Addin for Excel on French Windows. 

Error: 0x80028018 (-2147647512)
Description: Old Format or Invalid Type Library

His solution worked great on English Windows, but gave errors in any other language.  This is a known problem in Excel and there are a few workarounds that work depending on the way you’re writing your Excel Addin.   Let me take you through the problem, variations on the problem, and different solutions depending on which Visual Studio project template you choose to start your Addin.

The bug was originally documented in a KB 320369 article, which gives detailed repro steps, explanation, and two workarounds with sample code.  So why am I writing a blog post if the KB article covers everything?   Three reasons. 

  1. Because we’re fixing the problem in CLR 4 and I want to encourage you to use one of the recommended workarounds in your current solutions so that you’re ready when your users upgrade to .NET Framework 4. 
  2. Also, there are parts of the KB article that are a bit confusing, so I’ll try to add some color commentary to help explain what’s causing the problem. 
  3. And third, these problems do not occur if you use VSTO 2005 SE, VSTO 3.0 (which ships with Visual Studio 2008), or Visual Studio 2010.  I’ll explain why and how later.

The KB article describes the problem:

Error: 0x80028018 (-2147647512)
Description: Old Format or Invalid Type Library

You receive this error calling an Excel method when the following conditions are true:

  • The method requires an LCID (locale identifier).
  • You run an English version of Excel. However, the regional settings for the computer are configured for a non-English language.

If the client computer runs the English version of Excel and the locale for the current user is configured for a language other than English, Excel will try to locate the language pack for the configured language. If the language pack is not found, the error is reported.

The quote from the KB article is accurate, but can be confusing.  It is very difficult to determine if the Excel method you want to call requires LCID or not.  The Primary Interop Assembly (PIA) does not indicate whether or not the LCID is needed, however VBA does not hide the need for LCID.  Part of the reason why Excel hasn’t changed its methods is to maintain back compatibility with all the VBA code in the universe. 

Fixed in VSTO

VSTO implemented a fix in VSTO 2005 Second Edition (SE).  You can read more about this fix in Eric Carter’s blog post.  The fix is also in all subsequent versions of Visual Studio 2008 and will be in Visual Studio 2010.  You know you are using “VSTO” when you create a new Project in Visual Studio and select an Excel <version number> Workbook, Excel <version number> Template or Excel <version number> Addin.  The fix was not implemented in the Shared Addin template in any version of Visual Studio.  If you create a WinForms, WPF, Web or console application that calls Excel, then you will see this bug on non-English Windows.


If you are using the Shared Addin template, a WinForm, WPF, Web or Console application with any version of Visual Studio, then you should use the KB 320369 article to solve the problem.

The workaround is to write explicit calls to set the thread’s culture before calling into Excel.  You can then reset the culture back to what it was before after you are finished calling Excel. 

  • Install the Multilingual User Interface Pack for your version of Office.
  • Execute the Excel method or property by using InvokeMember so that you can specify the CultureInfo for the call. For example, the following code illustrates how you can invoke the Workbooks object Add method with "en-US" as the CultureInfo:
    Dim oApp As New Excel.Application()
    oApp.Visible = True
    oApp.UserControl = True
    Dim oBooks As Object = oApp.Workbooks
    Dim ci As System.Globalization.CultureInfo = New System.Globalization.CultureInfo("en-US")
    oBooks.GetType().InvokeMember("Add", Reflection.BindingFlags.InvokeMethod, Nothing, oBooks, Nothing, ci)


  • Or, instead of the above bullet and code sample, set the CultureInfo prior to calling the Excel method, and then you can reset it after your Excel call:
Dim oApp As New Excel.Application()
oApp.Visible = True
oApp.UserControl = True
Dim oldCI As System.Globalization.CultureInfo = _
System.Threading.Thread.CurrentThread.CurrentCulture = _
New System.Globalization.CultureInfo("en-US")
System.Threading.Thread.CurrentThread.CurrentCulture = oldCI

The .NET Framework 4 will solve this whole culture problem.  Excel is not going to change its culture sensitivity because of the need to support backwards compatibility.   Starting with CLR 4.0, when managed code calls into a COM component and an LCID is required, then the CLR will pass LCID = 1033.  Note that this is how VBA passes LCIDs.   This means that Visual Studio 2010 project templates for Excel Addins can stop wrapping all Excel projects with LCID proxy.   In the future, when you use VS 2010 and .NET 4 to write your Excel automation programs from a Shared Addin, console, Winforms, WPF, or Web application, you won’t need to wrap your calls either. 

-Christin Boyd, Program Manager & Misha Shneerson, Senior Developer

  • > And third, these problems do not occur if you use VSTO 2005 SE, VSTO 3.0 (which ships with Visual Studio 2008), or Visual Studio 2010.

    Sorry, but this cannot be true. I am using Visual Studio 2008 Professional Edition with SP1, .NET Framework 3.5 with SP1 and Excel 2007 and exactly this same error occurs. You will certainly believe me it took me a real pain in the neck to figure this out... .

  • Sorry, I might be wrong with my statement: The problem certainly is there in Office 2007, but since I am developing an Automation AddIn using a Visual Studio "Library Project" (instead of using Visual Studio Excel AddIn Project) I cannot say for sure if the bug's still there or not.

    However, when developing a Windows Form Application as suggested in MS's "steps to reproduce the behaviour" the bug occurs also.

  • Does this work for Japanese versions of Excel - I have tried en-US but that fails, it must be ja-JP, Is there any code I can write to handle US & Japan?

  • Ditto on the ja-JP question.  I'm having mutltiple customer report the "Old format or invalid type library" problem even though I set my current thread culture to "en-US".  Would this be the result of a non-English install of Office?  Is there a way to automate Excel interop when we don't know the language of the OS or Office install?

  • Just an update for the issue occuring when the Excel install isn't english.  Instead of using

    New System.Globalization.CultureInfo("en-US")

    you can retrieve the language of the Office install by using the following:  

    New System.Globalization.CultureInfo(  


    This requires references Office.dll v14.0

  • The additional workaround for Office 2007 & Office 2010 is slightly different for Office 2003 which is listed in the "KB 320369" article.

    Article bullet text for Office XP/2003:

    "Create a 1033 directory under C:\Program Files\Microsoft Office\Office11. Then, copy excel.exe to the 1033 directory, and rename it as xllex.dll. "

    For Office 2007 users you must copy (DO NOT CUT) the "xllex.dll" that is in C:\Program Files\Microsoft Office\OFFICE12\1033 into the following directory: C:\Program Files\Microsoft Office\Office12.

    For Office 2010 users you must copy (DO NOT CUT) the "xllex.dll" that is in C:\Program Files\Microsoft Office\OFFICE14\1033 into the following directory: C:\Program Files\Microsoft Office\Office14.

  • Hi guys,

    I am trying to install Requirements Analysis Tool and getting the error message saying " Cannot install setup or install program filename contains folders use Actions/CheckOut Instead"

    please help!


Page 1 of 1 (7 items)

BUG: “Old format or invalid type library” error when automating Excel (Christin Boyd)