The next version of my MZ-Tools add-in will target Visual Studio 2005, 2008 and 2010 so I can finally get rid of COM registration and native satellite DLLs and I can use a managed satellite DLL for custom pictures. I was using the “en-US” culture for the satellite DLL assembly and the same “en-US” name for the folder that contains it, and this was working fine for months using Visual Studio 2005/2008 in English on two computers, one with Spanish Windows XP and other with English Windows 7.
However, the other day, on the Spanish Windows XP computer loading the add-in in VS 2005 caused an FileNotFoundException saying that the satellite DLL with culture ‘es-ES’ (Spanish) was not found. In VS 2008 it worked fine. What the heck? That worked for months and anyway I thought that if some culture is not found, Windows, Visual Studio and whatever defaults to the English culture, but nope, using the Assembly Binding (Fushion) Log Viewer revealed that only the Spanish version was being searched for. What caused this problem?
It took me a while to discover the cause from the following facts:
- The Windows OS was in Spanish
- Visual Studio 2005 / 2008 were both in English
- Visual Studio uses the default value “Same as Microsoft Windows” in the Tools, Options window, Environment, International Settings section, Language combobox.
- If Visual Studio is not installed in the language of Windows, as it was the case, that setting is not honored and Visual Studio uses the language of the version that was installed, which was English.
- In the VS 2005 that caused the problem, changing that setting to use “English” rather than “Same as Microsoft Windows” solved the problem. So, somehow, VS 2005 got the Spanish version too, although I didn’t install it.
- When the “English” value was selected all project templates were fine, but when the “Same as Microsoft Windows” value was selected, most of the project templates disappeared, remaining only a few ones that gave me the clue that the product that brought the Spanish language to Visual Studio 2005 was a 3rd party product and Microsoft InfoPath 2007 and its Visual Studio Tools for Applications (VSTA) that I installed in Spanish some time ago. Since I was using VS 2008 most of the time, I didn’t notice this break until months later.
It happens that VSTA uses the Visual Studio 2005 Shell in integrated mode, so it affects the Visual Studio 2005 installation. However, it doesn’t seem to install all the resources in Spanish because the Visual Studio menus were in English, but the “Same as Microsoft Windows” setting was honored (using Spanish and causing the add-in to fail) and the project templates were filtered too.
The way for an add-in to know the language used by Visual Studio when the “Same as Microsoft Windows” setting is used is checking the EnvDTE.DTE.LocaleID property. I could have saved myself a few hours if I had included that piece of information in the exception report…
I am still trying to solve the problem of localized managed satellite DLLs (another ridiculous nightmare just to provide custom pictures) and when I find the solution I will update this article that currently fails in non-English Visual Studio versions:
HOWTO: Creating custom pictures for Visual Studio .NET add-ins commands,
buttons and toolwindows.
http://www.mztools.com/articles/2005/MZ2005007.aspx
I have posted too how to test add-ins in international versions of Visual Studio:
MZ-Tools Articles Series: HOWTO: Testing add-ins in localized versions of Visual Studio
https://www.visualstudioextensibility.com/2010/04/01/mz-tools-articles-series-howto-testing-add-ins-in-localized-versions-of-visual-studio