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

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