by Michael S. Kaplan, published on 2011/03/12 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/03/12/10140165.aspx
Now yesterday I wrote A resource segue, #2 (architecting the wheels off the wagon, a bit).
And the day before that I wrote A resource segue, #1.
Between them I've covered a bunch of the good and bad-ass about the version resources attached to win32 binaries on the Windows platform.
And a few odd digs about Visual Studio's place in the mix.
In a way those digs are unfair; I mean Visual Studio is one of the single most versatile and full-featured resource editors there is. The times when it does stuff slightly off that is often relly the fault of poor communication between parts of DEVDIV and Windows. I guess (being on Windows myself) it would be normal for me to blame DEVDIV, but I actually don't since it more often ends up being the fault of Windows.
Sorry about that, DEVDIV.
With that said, I'm about to point out some genuine problems they ought to fix over there, in some future version.
Like the next one. Or the one after that.
These are things that have been broken for five versions, so it would be silly to tell them they should be fired if they don' t drop everything to fix it next week.
Just one day, okay? :-)
As you might guess given the series we're in part 3 of, we're talking about version resources, still.
and Managed Code™.
If you build your small managed app in Visual Studio, it will automatically add a Win32 version resource with the same version number as the managed resources claim to be.
Easy.
This is a good interop story -- in Windows, anyone can right click on your app, choose Properties, and see the dialog.
And if you include an .RC file or a .RES file in the project that has a resource already, it will let you use that one instead. Which is nice.
Of course now we get to the problem.
Let's switch to WinForms. I'll make a form and put it in a language.
I'll choose Amharic, because that's kind of cool.
Not that the result is, mind you.
Here is the resource it sticks on the main binary:
and here is the one it puts on the resource DLL sitting in the am-ET subdirectory:
Ugh, where do I start?
First, the obvious -- even if I was running with the Amharic LIP it would never use the DLL's resources in that kind of mixed way that MUI-ized files do.
But why would they mark the language-specific binary Language Neutral, anyway?
And of course because of this one never gets to localize the version resources, like we can with Win32.
Which is kind of lame, I think. In fact except by the accident of the directory it is in you have no indication of what language that resource DLL is!
Now you could in theory run MUIRCT.EXE on your binary (described on MSDN here) and use it to create a WindowsFormApplication2.exe.mui that you could go off and localize -- in fact you can run it with the -F parameter to do just the version resource.
Of course you'll have to followmy advice about creating it with an .RC file or a .RES file, because MUIRCT.EXE won't split a language neutral file.
Now once youi do all this, you'll have three files:
And your localizer can localize that .MUI file and Windows will treat it the way it treats all of its files.
This may not be important to you, but when you think of the hundreds of managed code binaries that ship in Windows itself, the fact that you would have to ship a whole different file, per language, just to get parity with what Windows has been doing this exact same way since Vista, is a little silly.
Note that MUIRCT.EXE lets you specify another name for the resource file -- so you could in theory bind the managed resource dll in to let the whole MUI system treat the managed code the same way the native Win32 code works. So DEVDIV could totally make their binaries work with the Windows resource model without changing their own model.
But instead they just stay inconsistent in this way that makes for unlocalized/unlocalizable files....
I'd call it a terrible bug, but then the native story is a little messy these days too. So perhaps if both sides could clean up their acts a bit we could see everything working properly all at once!
Noam C. on 13 Mar 2011 9:19 AM:
"in Windows, anyone can _fight click_ on your app"?
That this some kind of Fight Club meets Windows thingamajig?
Michael S. Kaplan on 13 Mar 2011 9:34 AM:
"f" and "r" are pretty close together -- a legitimate typo. Or maybe a freudian keyslip about the relationship between the two orgs? :-)
referenced by
2011/03/14 Microsoft is better as one big company