Monthly Archives: March 2009

New Debugging Option For InstallShield 2009

2
Posted by admin on March 28, 2009 – 2:15 pm
Filed under Installations, Troubleshooting

The new InstallShield supports a very handy command line argument for debugging the handling of prerequisites.

Often times, you’ll have a prerequisite for your install that, for whatever reason, fails to run. When that happens, if you’ve properly set the launch conditions for your install to detect the installation of your prerequisites, your install will fail based on that launch condition.

This is a good thing, but it still begs the question; why did my prerequisite fail to install?

In my case, I had a preq for the .NET Framework 3.5. But my installation failed to run the prerequisite, so it failed at the launch condition because the 3.5 framework was not on the machine.

However, I had no idea why it didn’t run the .NET installer.

Even turning on Verbose MSI Logging, didn’t help, because IS runs prerequisites BEFORE the Windows Installer kicks in, so the verbose log won’t include anything about what happens when the preqs are run.

With the new InstallShield 2009, though, your SETUP.EXE supports a new switch, /DEBUGLOG.

Use it like this:

MySetup.exe /DEBUGLOG”Path and file to debuglog”

note there’s NO SPACE between DEBUGLOG and the “.

so you might use:

MySetup.exe /DEBUGLOG”c:\debug.log”

Doing so revealed that the bootstrapper was, indeed, attempting to run the .NET Framework installer, but that it was failing. Unfortunately, It did not indicate the reason for the failure. Here’s the pertinent snippet from the log:

1-23-2009[01:10:15 PM]: Extracting ‘Microsoft .NET Framework 3.5 SP1.prq’ to C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{D4907620-651C-4FA9-9B3F-FCE2FCADB41A}\Microsoft .NET Framework 3.5 SP1.prq
1-23-2009[01:10:15 PM]: PrereqEngine: condition,2,2,HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5,SP,,1 — Successful
1-23-2009[01:10:15 PM]: PrereqEngine: operatingsystemcondition,5,1,2, — Failed!,
1-23-2009[01:10:15 PM]: PrereqEngine: operatingsystemcondition,5,2, — Failed!,
1-23-2009[01:10:15 PM]: PrereqEngine: operatingsystemcondition,5,2, — Failed!,
1-23-2009[01:10:15 PM]: PrereqEngine: operatingsystemcondition,6, — Failed!,
1-23-2009[01:10:15 PM]: PrereqEngine: operatingsystemcondition,6, — Failed!,
1-23-2009[01:10:15 PM]: PrereqEngine: operatingsystemcondition,6, — Failed!,
1-23-2009[01:10:15 PM]: PrereqEngine: file,AD29C3DEC8FB0CFDAFE8548371B0EE6D,<ISProductFolder>\SetupPrerequisites\Microsoft .net\3.5 SP1\Full\Helper.exe,http://saturn.installshield.com/devstudio/setuprequirements/Microsoft .net/3.5/Helper.exe,,, — Successful,
1-23-2009[01:10:15 PM]: PrereqEngine: file,,<ISProductFolder>\SetupPrerequisites\Microsoft .net\3.5 SP1\Full\dotnetfx35.exe,http://download.microsoft.com/download/2/0/e/20e90413-712f-438c-988e-fdaa79a8ac3d/dotnetfx35.exe,,, — Successful,
1-23-2009[01:10:15 PM]: PrereqEngine: execute,Helper.exe,/p dotnetfx35.exe /l 1033 /v “/q /norestart”,/p dotnetfx35.exe /l 1033 /v “/q /norestart”,1641,3010,, — Successful
1-23-2009[01:10:15 PM]: PrereqEngine: Id,{074EE22F-2485-4FED-83D1-AAC36C3D9ED0},http://saturn.installshield.com/is/prerequisites/microsoft .net framework 3.5 sp1.prq, — Successful
1-23-2009[01:10:15 PM]: PrereqEngine: behavior,Optional,,Reboot,2,Failure,
1-23-2009[01:10:15 PM]: PrereqEngine: Lua,
1-23-2009[01:10:15 PM]: PrereqEngine: Hidden,1
1-23-2009[01:10:15 PM]: PrereqEngine: MsiProgress,
1-23-2009[01:10:15 PM]: Skipping prerequisite ‘Microsoft .NET Framework 3.5 SP1.prq’ because it was installed before the reboot

Since things seemed to point to the .NET Installer, I ran it manually. Lo and behold, it failed because I didn’t have SP2 installed on this virtual machine.

Duh!

But that DEBUGLOG switch definitely helped point the way.

Chained MSIs in InstallShield 2009

0
Posted by admin on March 27, 2009 – 10:12 pm
Filed under Installations

One of the big features new to Windows Installer 4.5 and InstallShield 2009 is the ability to chain MSI files. If you’re not familiar with the concept, MSI chaining is the ability for your installation to seamlessly install other installation packages without resorting to special case merge modules or other trickery.

Say your application needs to install SQL Express 2005. Set SQL Express up as a chained MSI and it will be seamlessly installed when your app is installed.

Now, at least some of this was possible under older versions of Windows Installer, but it wasn’t particularly pretty, or seamless.

However, start playing with it and the shine quickly wears off to reveal that, as usual, it’s a half-implemented feature.

The biggest problem I’ve run into so far? VSTO3.0.

Microsoft released VSTO 3.0 as a single SETUP.EXE. You can’t chain a SETUP.EXE though.

Strike one.

But, you CAN start the VSTO 3.0 installation, wait till it gets to it’s first screen, then grab all the contents of the installation that get dumped to a temp folder on the C: drive. In that bunch of files is the actual MSI that gets installed.

That MSI, you can chain just fine.

Ah, first base.

Try and deploy though and you’ll likely get messages about an interface having to do with SmartTags being missing. Come to find out, that was a big oops in the first release of VSTO 3.0, so Microsoft released VSTO 3.0 SP1. It also is a SETUP.EXE, but, upon extracting it, it actually consists of an MSP file (a PATCH) and not an MSI file.

And you cannot  chain a patch file.

Strike 2.

Now, normally, patches can be applied to an MSI as a transform to create a new MSI, complete with the patch. But it appears that the VSTO 3.0 SP1 patch wasn’t authored with that in mind, as I could never, even with the help of Accresso support, actually apply the patch to my VSTO 3.0 MSI file.

Strike 3. Game over.

In the end, I had to resort to InstallShield Prerequisites, workable, but not near as clean as chained MSI installations.

Getting InstallShield Prerequisite Conditions to Function Properly

435
Posted by admin on March 27, 2009 – 10:09 pm
Filed under Installations

Here’s the “Prerequisite condition editor” dialog from InstallShield 2009:

image

The first snag I ran into was determining what the difference was between a registry entry having a “specified value” and one having a “specified version value”.

It’s certainly not clear from this dialog, since both options show the same set of properties at the bottom of the screen.

It’s also not in the help file or documentation online anywhere that I could find.

Come to find out, the former performs a “stringwise” comparison, whereas the latter performs a numeric comparison. Pretty important distinction.

Then there’s that “Run this prerequisite if the specified registry value data has the following relationship to the existing data” frame. huhwha?

I had to read that one more than a few times to grok what it’s actually trying to say, and that’s never a good sign.

Top it off with the fact that a call to InstallShield support verified that the sentence logic itself is backwards. Even the developers couldn’t read it right!

End result. Let’s say you want to install your prerequisite if registry value x is non-existent or 1.

In that case, you’d need to set the condition as a “Registry entry has a specified version value” type condition, you’d set the registry key and value names appropriately, and finally you’d set a “value data” to 1 and set the relationship to “is less than”, even though that is the opposite of what the dialog reads.

Fonts that Won’t Install

0
Posted by admin on March 24, 2009 – 2:58 am
Filed under Fonts

image I’ve collected a good number of fonts over the years, but recently, when I went looking for a font for a particular purpose, I noticed that a sizable number wouldn’t install under Vista, the installation process responding with a message indicating that the font was corrupted.

My first thought was VIRUS! But after checking a number of files, they all appears more or less like TTF files that would install.

It was highly unlikely that this number of fonts just “became” corrupted, so I started researching the problem.

Come to find out, true type font files contain a number of descriptive fields such as the name, family of the font, style and so on.

Under Windows 95, Win2K and even earlier Windows XP, these extra fields were essentially ignored.

BUT, under Windows Vista (and, apparently Windows XP SP2), these fields MUST BE FILLED or Windows will indicate that the font is corrupt.

So the question became, “How the heck do I fill in those fields?”

Font Creator to the rescue.

This is a nifty little program that allows you to edit TTF files, glyphs and all. Now, I’m no professional typographer, but I’d played with Font Creator several times in the past to cobble together special purpose fonts for one reason or another.

I downloaded the newest 5.6 eval version, installed and tried loading a font. Sure enough Font Creator could load all these “corrupted” fonts just fine.

So I started poking around until I came across the Tools/AutoNaming menu option.

Select it, let it suggestion names for all the various font descriptive fields, and the save the font.

Bam! The font is fixed and installed just like it’s supposed to.

Very cool.

Full Hard Disk Backup under Vista

0
Posted by admin on March 15, 2009 – 10:11 pm
Filed under Uncategorized

Finally, something that actually works fairly nicely under Vista

Microsoft includes a tool with Vista (I have Vista Ultimate, I’m not sure if this is included on all versions of Vista or not), that can backup your entire harddisk (usually one at a time, but for most people these days, drive C IS their harddrive) all at once, WITHOUT resorting to funky dos boot disks and the like.

It’s called Backup Your Entire Computer (catchy, eh?), and it’s located in the Backup and Restore Center on the Control Panel.

image

Basically, grab yourself a USB drive big enough to hold your entire C drive, open this window and click the Back up Computer” button.

It could take a while, so USB 2.0 is best, esp if you have several hundred gig to back up.

But, there’s an even handier way to work with it!

The command line utility wbadmin (Windows Backup Administrator) allows you to perform a complete computer backup directly via command line (or, more conveniently, via a batch file).

You run it like this:

wbadmin start backup -backuptarget:k: -allcritical -quiet -vssFull

where k: is the drive letter of the USB drive that you want to backup onto.

Couple that with the Task Scheduler to run this batch file automatically every night and you have a nice, simple way to guarantee that your drive is completely backed up.

And finally, Windows Backup creates a VHD file from your harddrive as the backup. Anyone familiar with Virtual PC might recognize VHD files as Virtual HardDisks.

And that might also mean you could open that vhd file without actually having to restore the entire thing. And you’d be right! Very cool. The details on doing so are fairly involved, but mainly it requires that you install the free Microsoft Virtual Server, if only for the Mount Virtual Hard Disk tool, which comes with Virtual Server.

Once you have that tool installed, you can mount a VHD back up file and it will appear to be just another harddrive on your computer. You can actually copy files from it or to it at will.

It’s not as easy as it should be, but it’s not too tough. Bart DeSmet has a really good description of doing exactly this on his site.

Debugging VSTO problems

0
Posted by admin on March 12, 2009 – 10:19 pm
Filed under Uncategorized

If you’ve ever worked on a VSTO addin, you may know how frustrating it can be to try debugging problems with them, especially problems of the “my addin isn’t being loaded” variety.

There is a way to get a little more information on the process, however.

Just set the environment variable VSTO_SUPRESSDISPLAYALERTS to “0”, and then restart the Office app of you choice.

Now, instead of just quietly failing, the VSTO loader should be a little more verbose about what’s happening.

In my particular case, it didn’t help all that much, but I could definitely see it helping in many cases.

Microsoft also has a KB article about it, but you’d almost never find it unless you knew what your were looking for up front.