Vista changes .Net 2.0 Locale Names, sample work around custom cultures/locales
[10 July 2007] The recent security patch to .Net changed the behavior on other Windows versions as well (XP, 2003, 2000). If your application still requires the old names this workaround might work for you.
In order to follow RFC 4646 more closely (formerly RFC 3066 bis) we changed managed locale names in Windows Vista. Some applications had a dependency on the old names, in which case the suggested work around is to create custom cultures from the new locales with the old names.
An example MakeCultures.cs to do just that is attached. Copy it somewhere, make sure %windir%\Microsoft.Net\Framework\v2.0.50727 is in your path and then compile & run it. Voilá!, new "old" cultures.
path=%path%;%windir%\Microsoft.Net\Framework\v2.0.50727
csc /r:sysglobl.dll MakeCultures.cs
MakeCultures.exe
In addition to being a workaround, the .cs file is an example of making a trivial culture. Note that the "old" names are really non-standard, so the preferred solution is to make your app work with the correct names so that there aren't problems with other apps. For example, if someone made this their user locale, then their http-accept-language would be wrong when IE7 asked a server for a web page. This might get you out of a bind though until a better solution can be created.
[6 June 2007] I updated the attached MakeCultures.cs example (see below) to include the alias "old" names as the culture parent when asking for the cultures by their "old" names. This allows existing applications with resources under the old names to load those resources even if the user's locale is specified using the new name. Unfortunately this is either-or. You can't have the old cultures have the new cultures as parents as well, so this might not solve all problems.