Home > Software Deployment > PRODUCTLANGUAGE is still ProductLanguage

PRODUCTLANGUAGE is still ProductLanguage

Lesson learned: PRODUCTLANGUAGE is still ProductLanguage, so don’t use it as a custom property because it’s a reserved keyword even though Installshield allows you to add it.

I had a frustrating day working on a mysterious Jira and I’m going to discuss it for the benefit of those who helped me on twitter. Thanks @robertdickau @chrpai @installsite

User reported an application would crash on startup on silent install, but worked fine for attended installs. eventvwr only mentioned a .net 2.0 error, but after installing on my development machine I was able to obtain a stack trace.

Retrieved the code from our depot and found the offending GetLanguage() function on the top of the stack trace. It was looking for a registry key that should be set by the installer but was missing. (I’ll write up a change request for the group that works on this app because I don’t think an app should crash because of missing reg key 🙂 )

msi install log showed the component was selected to install (Request: Local;), but the Action was Null (Action: Null;), which tells me it’s failing to install because of the component condition:

MSI (s) (54:0C) [14:24:46:591]: Component: L_ENU_BT_REG_HKLM; Installed: Absent; Request: Local; Action: Null; Client State: Unknown

The component condition we had in the installer was:
(UI_INSTALL=”YES” AND ProductLanguage=1033) or (UI_INSTALL=”NO” AND PRODUCTLANGUAGE=1033)

The msi log said it was deleting this property basically at the start of the log so this explained why the condition was never evaluating as true on /qn installs:
PROPERTY CHANGE: Deleting PRODUCTLANGUAGE property. Its current value is ‘BLANK’

But why was it deleting my property?! After spending some time poking around in the Installscript, C++ dll and C# dll I couldnt’ find a reference to it being deleted I gave up and asked for help on twitter.

@robertdickau was on the right path:
Does anything change if you use a different name (say, PL)? There’s already a ProductLanguage property built in…

Sure enough, if I add a custom property to a new project named PRODUCTLANGUAGE I see it also gets deleted. Discovering this leaves me to conclude PRODUCTLANGAUGE, even though it’s caps and IS let’s you insert it into the property table, is indeed a reserved property name. I would recommend Installshield dis-allow users adding reserved keywords such as this to the property table.

Chris Painter suggests:
@buildmaestro also test against old msi runtimes to see if the behavior changed.

Of course I did this and I see this was a problem all the way back to 2007.

For the heck of it, I wanted to see if maybe this did work at one time with a different environment. I’m testing against Windows Installer 4.5, .. maybe an older version of Windows Installer handled this? So I fired up an ancient image of Windows 2000 that used Windows Installer 2.0 and while I didn’t see the msi log explicity say it was deleting the property, it also wasn’t listed in the “Property(s)” dump at the end of the log. I assume it also deleted the property.

I have to wonder, did anyone ever test this functionality!?! ha. Why did they create a copy of the ProductLanguage variable when ProductLanguage is also accessible on silent installs…? All I can do at this point is fix the problem and be happy nobody has reported this failure.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: