S h o r t S t o r i e s

// Tales from software development

Archive for September 2009


leave a comment »

I created an installer from scratch last week using WiX for the project I’m currently working on. Earlier this week I went to my client’s offices and ran the installer on one of their servers.

After the install completed successfully I quickly checked that the deployed software was functioning correctly. Everything looked OK until I manually ran a scheduled task that the installer created and it failed. It appeared that a COM component that the program called was not registered but when I ran the program in a command window it ran without any problems.

It took me a few minutes to realise what the problem was and how I’d caused it.

One of the installation actions is to install and register a COM library used by the program that the scheduled task calls. When I ran the program in a command Window it executed successfully but the scheduled task runs under a service account and this failed with a ‘Class not found’ error message.

The problem was that because I hadn’t specified the ALLUSERS property in the WiX file for the installer, the default value of “” (empty string) was used which creates a ‘per user’ install. One of the differences between a per-machine and a per-user installation is that COM Registration information is written under the HKCU (current user) registry key instead of the HKLM (local machine) key.

So, the COM component was only registered in the context of the account I was logged in with when the installer ran and it wasn’t registered in the context of the service account that the scheduled task runs under.

All that’s required to fix this is to set the ALLUSERS property to 1 by including a Property element for it under the Product element, e.g.

<!– Set ALLUSERS=1 to create a per machine install rather than a per user install. –>
  <Property Id=”ALLUSERS”><![CDATA[1]]></Property>

There’s a useful explanation of the differences between a per-machine and a per-user install on the MSDN website.


Written by Sea Monkey

September 29, 2009 at 6:00 pm

Posted in Deployment

Tagged with

Microsoft knows what's best for you, apparently.

leave a comment »

I’ve just purchased a data cable for my motorbike.

Yes, you read that correctly! Perhaps this is the ultimate USB attached accessory for your laptop…

Even more bizarrely, this state of the art USB accessory has a Harley-Davidson engine that was originally designed in the late 1950s. It’s been brought it up to date in a number of ways including using an ECU to control the fuel injection.

Anyway, back to that data cable… The supplier emailed me a copy of the software that’s used with the data cable to interrogate the ECU. When I opened the email in Hotmail and saw the .exe file attachment my heart sank as I knew that I was going to have problems downloading the file.

My various attempts to get the file always resulted in this message being displayed in Hotmail:

Windows Live Hotmail has blocked some attachments in this message because they appear to be unsafe.

Naively, I assumed that there would be a procedure that allowed me to override this nannying and to download the file. I was wrong. Once Hotmail has decided to block an attachment, that’s it.

I understand why Microsoft has done this but it’s outrageous that the service that I pay for (I subscribe to Hotmail Plus) is refusing me access to a file that has not only been legally and lawfully sent to me but that I’ve actually purchased.

Thanks Microsoft.

Written by Sea Monkey

September 24, 2009 at 7:00 am

Posted in Comment

Tagged with