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.

csc /r:sysglobl.dll MakeCultures.cs

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.


Comments (7)
  1. In order to conform to RFC 4646 (replaces RFC 3066), we updated the names of some locales, which can

  2. I updated the sample for Vista changes .Net 2.0 Locale Names, sample work around custom cultures/locales

  3. The .Net patch of July 10th changes culture names to conform to the standards. KB 939949 deals with this

  4. CoqBlog says:

    Après avoir installer un des patch de juillet ( KB928365 du bulletin MS07-040 ), il est possible que

  5. NotFooled says:

    Microsoft fails to mention that the MakeCultures.cs workaround only helps if the person already has installed the problem causing security patch.  It does no good otherwise.  Maybe Microsoft should re-release the security patch with this fix wrapped in so us application developers don’t need to deal with the pain and deploy these patches to complaining customers throughout the world.  Get a clue Microsoft.

  6. It is worth noting that it doesn’t "fix" all cases.  Most applications don’t have any problems, but for those that do this fix helps many of them.  Other users may need to switch which culture is the parent of the other to get resources to load as expected, and some applications may have subtler dependencies that neither technique would address.  Unfortunately these and other issues make it difficult to build in an appropriate workaround.

Comments are closed.

Skip to main content