How VSTO solves the Excel LCID or Locale issue in the June CTP build

  • Article

The June CTP of Visual Studio 2005 is now live on MSDN.

In this build, you will find that VSTO has added a feature to address the Excel LCID or Locale issue. What is the Excel Locale issue? Well, if you run a VSTO customization for Excel on a machine that has the locale set to something other than US English (locale ID or LCID 1033) you will get an error. Something like:

Exception from HRESULT: 0x800A03EC 

or

Old format or invalid type library.

To get around this error you had to install a file called xllex.dll by installing the Multilingual User Inferface pack (MUI) for Excel. There is also a workaround. You can create a 1033 directory under Microsoft Office\Office11, copy excel.exe to the 1033 directory, and rename it to be xllex.dll.

Even after you get around this first issue, when you call the Excel object model in locales other than US English, the Excel object model can act differently and your code can fail in ways you may not have thought of. For example, you might have code that sets the value of a range to a date:

myRange.Value2 = "08/12/05"

Depending on the locale this code can act differently resulting in Excel putting into the range any of the following values:

August 12, 2005
December 8, 2005
December 5, 2008

Other code you write can be affected as well--you might have code that sets or checks for a formula using the "Sum()" function but this will break in different locales because the Sum function might be localized to some other string like "Summe()".

VBA users didn't ever have to worry about this because no matter what locale your VBA code ran in, VBA always talked to the Excel object model as if you were in the US English locale (also known as the 1033 Locale ID).

In the June CTP we have added a feature that make VSTO act like VBA in this regard for Excel.

VSTO code behind the document solutions solve the Excel locale issue by using a transparent proxy object that sits between you and the Excel object model. You can learn more about tranparent proxies if you are interested by reading Chris Brumme's blog entry here:

https://blogs.msdn.com/cbrumme/archive/2003/07/14/51495.aspx

Our transparent proxy object always tells Excel that the locale is US English (locale id 1033) which effectively makes VSTO match VBA behavior.  If you are using VSTO code behind the document solutions, the Excel locale issue is solved for you and you do not have to worry about it further.  If you are building a managed COM add-in for Excel or an automation executable, the issue still exists. 

There are some caveats to VSTO’s solution to the Excel locale issue. The VSTO transparent proxy can slow down your code slightly. If you want to bypass VSTO’s transparent proxy for a particular object, we will provide a way in RTM to unwrap to the raw PIA and expose you once again to the locale issue. Also in RTM, (or the July CTP) there will be an assembly level attribute called ExcelLocale1033 in the VSTO project's AssemblyInfo.cs file that can be set to false to turn the transparent proxy off for the entire Excel solution.

Finally, if you create a new instance of the Excel Application object from a Word VSTO code behind solution, you are talking directly to the Excel PIA with no transparent proxy object and the locale issue will continue to be in effect.