By design? Well, not beautifully so....

by Michael S. Kaplan, published on 2006/12/29 03:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/12/29/1378466.aspx

So the message I got yesterday from someone with the handle IDisposable was:

RE: http://blogs.msdn.com/michkap/archive/2006/03/25/560838.aspx

This code doesn't work under Vista mostly because the Language Packs won't install (says they are already there), but the load of the Satellite assembly doesn't work (obviously) since the localized directories don't exist.

Help me, Obi Wan.

Ok, I'm kidding, it is actually the same Marc Brooks who came up during that blog post he is pointing to. IDisposable is just Marc's handle. I don't think he has it as a license plate though, so he is not as far gone as Mark Davis (president of the Unicode Consortium) whose license plate is UNICODE. :-)

Anyway, I tried it out with several of the language packs, both for 1.1 and 2.0. Now allowing for the fact that I had to of course run them from an elevated command prompt, I had a 100% success rate for the 1.1 language packs, and a 0% success rate for the 2.0 language packs.

Marc is right. Even though 2.0 the langpack setups claim that they are already installed, they are not.

This is, unfortunately, by design.

An excerpt from a soon-to-be-available KB article:

When attempting to install an x86 .NET Framework 2.0 redistributable Language Pack (langpack.exe) on Vista x86, the installation will not fail but will result in no action.

When attempting an interactive install of an ia64 or x64.NET Framework 2.0 redistributable Language Pack (langpack.exe) on the corresponding Vista OS, the install will block with a dialog message: "The product has been already installed."  Silent ia64 and x64 installs will succeed, but result in no action.

In order to support existing application installers, including Visual Studio deployment projects, Vista’s registry will reflect a system with all .NET Framework 2.0 Language Packs installed (see standard keys below). This allows existing installers to succeed when probing the registry to detect language pack existence, installation or repair success. Attempts to install or repair version 2.0 language packs will result in a success (0) being returned immediately, but will result in no actions to the underlying system configuration. Whether .NET Framework 2.0 language components are, in fact, actually installed on a given Vista system will depend upon the set of Vista UI languages installed.  

Basically, given that the .NET Framework is considered to be a component of the operating system, the language packs are something that can only be installed as a part of the Windows user interface language support intrinsic in the MUI and LIP technologies.

So Marc is technically incorrect that the code I posted fails; it will work if you install a Vista MUI langpack or a Vista Language Interface Pack, for every language that you have installed. But the current plan of record for the behavior of the .NET Framework language packs is that they go hand-in-glove with the operating system's, starting in Vista.

I verified this on my machine with all of the pre-ship versions of the MUI langpcks -- this is working as designed and I got the following output running my code:

file:///E:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
 ar
 zh-CHS
 cs
 da
 el
 es
 fi
 fr
 he
 hu
 it
 ja
 ko
 nl
 no
 pl
 pt
 ru
 sv
 tr
 pt-BR
 zh-CHT

So if you have the Vista MUI langpacks if they are available to you then the .NET Framework langpacks will work.

(the preliminary LIP Vista LIP langpacks are not done ednough for me to know whether they include the .NET Framework resources or not; given that the LIP list is larger than the .NET Framework list, I assume in many cases it may not be there.)

In my opinion, given that design, at a minimum the fact that the langpack setups claim that the component is already installed (rather then the more accurate claim that the component cannot be installed on this platform) is a legitimate bug.

The fact that the download pages claim that Vista is supported is also (in my opinion) an obvious bug, since as far as these packages are concerned Vista is not supported.

Now the last point is the fact that these langpacks are designed not to install on Vista. That part was intentional, so it is (technically) by design.

I won't go so far as to claim that I am thrilled about the design here, FWIW.

Though to be honest the whole MUI licensing model is something that I won't claim to be thrilled about, either (and have not been since the Windows 2000 MUI licensing was worked out). So linking one to the other with no other option is a bad idea, in my opinion, not just for the sake of this one bug, but for the same reason why a person doesn't go to the boring party if they are used to ones that are fun. If you know what I mean.

Neither of them is one I have a whole lot of control over, of course.

In any case, I will see what I can do to keep raising the issue, and anyone who would like to see something different should probably feel free to do the same (here or in the issue Marc raised on the Feedback site here)

But just so you know, the current behavior is considered by design.

This post brought to you by 𒁁 (U+12041, a.k.a. CUNEIFORM SIGN BAD)

# Tom Gewecke on 29 Dec 2006 10:11 AM:

# Michael S. Kaplan on 29 Dec 2006 11:29 AM:

# IDisposable on 29 Dec 2006 3:21 PM:

# Michael S. Kaplan on 29 Dec 2006 5:12 PM:

# Mihai on 29 Dec 2006 11:39 PM:

# Michael S. Kaplan on 29 Dec 2006 11:42 PM:

referenced by

go to newer or older post, or back to index or month or day