by Michael S. Kaplan, published on 2007/01/02 03:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/01/02/1396598.aspx
So the other day when I posted By design? Well, not beautifully so.... it was nice to see that Aaron Stebner posted on some of the underlying setup issues behind it in his post Why .NET Framework 2.0 language packs will not install correctly on Windows Vista, as well as how to work around the issue if you'd really rather just install the little buggers and not have the .NET Framework lie and claim that they are there when they are not.
Though for what its worth I disagree with both Arron's and Marc's (original) characterization that the code I posted in Enumerating available localized language resources in .NET is flawed or broken. I am actually quite proud of the fact that my code honestly returns the information on the machine irregardless of the weird licensing rules of Windows and the fibs that .NET Framework language packs tell!
Anyway, this post is not about any of that, really.
It is actually about an issue that Marc keeps bringing up, whether it is here or here or his comments on the feedback site here, basically an unhappiness in the way that having the download pages for the various language packs localized into.
Now the scenario that makes this reasonable is the one I described in If you can't read it, don't switch to it!. And as far as that goes, it is a reasonable scenario.
Anyone who does not see the logic of the scenario is probably in denial.
However, there is another scenario here, one that impacts both managed and unmanaged applications, and which actually is the real limitation that Marc is hitting.
The scenario relates to the times that you need to install all languages on a server (like a web server or a terminal server).
In my mind I think of it as "The Shawn Scenario™" since my colleague Shawn Steele has consistently been the most likely person on the NLS dev team to mention the "what if you were on a web server and..." kind of scenario in a dev meeting. :-)
Now in that case, the person who would reasonably expected to be doing the installation of UI language resources is not likely to know all of the languages in question, and thus requiring the person installing all of the languages to know all of them is unrealistic.
Beyond the language issue, is it really reasonable to have them all be separate installs in this case? That is just time consuming and annoying, right? So it seems like it is not just the language issues that are annoying here -- it is the whole way that the langpacks exclusively exist that kind of conflicts with a reasonable scenario that is a problem here!
Since the scenario of a web server having all of the .NET Framework's UI languages available for ASP.NET is just as reasonable as a terminal server that people all over the world log into having all of the MUI languages installed, it is clear that in addition to the need for installs whose UI language is the same as the language being installed, there needs to be coverage of this other scenario where all of the languages can be installed at once.
Windows has this covered for MUI (and if you have all of the MUI langpacks in a single flat location you can install all of them at once), but currently the .NET Framework does not. In the long run, I think it would be a good scenario to cover.
Perhaps they could even fix the other problem where it claims the languages are installed -- I have some code that will them the real install story if they need it! :-)
This post brought to you by װ (U+05f0, a.k.a. HEBREW LIGATURE YIDDISH DOUBLE VAV)
# Marc C Brooks on 2 Jan 2007 7:06 PM:
You are right, the code to enumerate the languages is completely correct. I was in error believing the stupid language pack's error message (that the language pack was installed, it clearly wasn't once I dove further).
Once I found that the enumeration code was working correctly, I sent you that second message about WHY it was failing, and how the installations of the language packs was wrong.
I'm sorry I wasn't clearer in retracting the original complaint (you'll note I never blogged about that issue).
As it stands, the only thing I don't like about that code is the enormous number of exceptions it causes (that we catch)... I don't like that any more than I like catching Int32.Parse exceptions.
# Michael S. Kaplan on 2 Jan 2007 9:08 PM:
Which exceptions do you mean?
# Marc C Brooks on 4 Jan 2007 1:35 AM:
The ones caught by:
foreach(CultureInfo ci in CultureInfo.GetCultures(CultureTypes.SpecificCultures | CultureTypes.NeutralCultures)) {
try {
Assembly satellite = assembly.GetSatelliteAssembly(ci);
// If we made it this far, we have the resources
Console.WriteLine("\t" + ci.Name);
}
catch(FileNotFoundException) {
// Swallow this exception, it means no such
// resources exist for the given language
}
}
For each locale NOT installed. Throwing exceptions isn't cheap. It would be so much better if there was a TryGetSatelliteAssembly that just returned a bool false if the assembly (or its fallbacks) aren't there.
# Michael S. Kaplan on 4 Jan 2007 1:47 AM:
There is also the more complicated code to just look for where the file would be in this case. Maybe something I could write up this weekend. :-)