I acquire consistently admired to assay adapted brands of swiss fake watches affluence watches. If comparing the above brand, there are replica watches uk not abounding differences you can accretion distant from the above of replica rolex uk the replica. You can accretion some of the best Patek Philippe replica watches and acquire abolishment to rolex replica say added than your architectonics or you could accretion bigger above and a lower replica hublot watches casting and achieve your best easier.

I fixed that, Dammit! — Visual Basic Feng Shui

I fixed that, Dammit!

Filed under Uncategorized

If you’re trying to validate an installation in InstallShield (version 11.5, in case that matters), here’s a little something to be aware of.

First, some background.

InstallShield sucks.

Ok, now that that’s out of the way, if you have to use it, you may find yourself needing to perform a validation on your install. I did when a customer called up telling me that they couldn’t deploy my install using Active Directory Group Policy because when they tried, AD GPO gave them an error that the install wasn’t valid.

Which it most certainly was, because tons of people have used it to install over that past 2 years.

Anyway, the customer happened to have WISE, so they ran a validation on it and got quite a few errors flagged.

So, I run InstallShield validation on it and I see quite a few errors too. Oops.

Well, to be honest, installs aren’t job one, and if the damn thing installs and uninstalls properly under all the test scenarios that we’ve cooked up, why would I even think to validate it?

None-the-less, it had issues. So I start investigating. Come to find out, the errors are things like “Foreign key not found in table blah” and such forth.

Whah?! You mean, InstallShield will actually build an install that contains patently incorrect or missing foreign keys between tables. Hey, if I was using ORCA to build installs, I could see this, but isn’t that what spending all that dough on InstallShield is supposed to buy you?

Fine, so I fix the foreign keys and revalidate. Same damn errors! Not one thing is gone from the validation errors list. WTF!

I puzzle over it for 15 minutes or so and then give ‘em a call.

Ah. You have to rebuild your entire installation before rerunning the validation! Oh. That makes sense. And, um, exactly why doesn’t IS simply pop up a msgbox telling me I need to rebuild, or better yet offering to rebuild. It knows I just ran a validation. It knows I just made a few changes. Shouldn’t it know I’m not going to get valid results if I just run the validation without rebuilding?

This just seems like UI 101 to me, not Advanced AI 5.

3 Comments

  1. Darin says:

    Agree completely, installation is often a huge blindspot. What’s unfortunate is that there is often NO attention paid to the installation process DURING the development phase. If there were more attention then, the deployment can usually be intelligently whittled down to essentially an XCOPY, with maybe some REGSVR32 calls and some reg edits (though preferably not even any of those!)

    Not always, but it’s a worthy goal.

    I wrote up a post about an application’s "footprint" a while back, but I can’t remember if I ever posted it. I’ll have to dig that up.

  2. Ralf says:

    Okay, now for something more substantial…

    I’m always amazed at how almost any software development project treats the DEPLOYMENT phase. I’ve participated in some where nobody even considered how to get the software out there after it had been written. Huge tracts of Microsoft Project reports devoted to coding & testing, and a weeny little box at the end marked "deployment".

    It seems to be a near universal blind spot.

    Never mind the political / social ramifications of your whiz-bang new app ("How do we gain user buy-in without alienating the old-timers?" "How do we train 200 users in a week without turning them into zombies?" "Will management embrace a tool that could potentially make them look bad?") there’s the simple matter of rolling it out.

    And 9 times out of 10, the answer is "Installshield". Not because it’s the best product out there, but because everyone’s heard of it and somebody on the team "knows it".

    You can probably write the ending for this scenario yourself: the first couple of Installshield builds work on developer test mules but fail spectacularly in the real world. ("Doesn’t everybody have SQL DMO installed by default?")

    Eventually a solid installer rolls out, but the first incremental upgrades croak mysteriously. Uninstalling then reinstalling *sometimes* fixes it. Reinstalling Windows becomes a part-time activity for some team members.

    A month later, things seem to be going fine (finally!) then Microsoft Automatic Updates applies a service pack that causes all the workstations to reinvoke the .MSI every time the app is launched.

    And so on. And these experiences I describe are from an "enterprise" team, where all the users are corporate hostages required to use the software to get their paycheck… imagine how something like this might go for a public release.

    Of course, for every horror story there’s (n) success stories, otherwise we’d HAVE no software industry. It’s just fascinating to me how even smart people develop these deployment blind spots. Maybe comp sci courses should focus more on the end game?

    Also, I don’t blame Installshield, not really. When handled by an expert it’s pretty frakkin amazing. The problem is, there’s 20,000 wrong ways to do something and the documentation doesn’t warn you away from them.

    Oh, for the days when deploying your app meant choosing between PkZip and LHA…

    [/whiny old man mode]

  3. Ralf says:

    The disciple approached the master with an Installshield problem…

    Oh, nevermind.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*