Environment and Path Variables in InstallShield

For whatever reason I have either never had a reason to use an Environment Variable for a Path Variable in InstallShield before now, or it’s been long enough that I forgot how to do it so this morning when I went in to try and set one up I was a bit surprised to find it to not be quite as straightforward as I thought it might be.

I had originally just gone straight to the Path Variables section of the IDE [EDIT: after creating the environment variable before starting InstallShield] and created a new Path Variable entry and changed the type to “Environment” however no matter what I did I could not get it to resolve to the value of the Environment Variable that I had already created. The help files were no help and I didn’t see anything in a quick search on the InstallShield Community Forums (which are normally a great resource for exactly this sort of problem). I had been using InstallShield 2009 Professional and verified that it worked the same ways in 2010 and 2011. Eventually I stumbled on to this method:

  1. Create the environment variable on the system first through the usual methods.
  2. Open the InstallShield project that you want to use the variable in. (If you have the project open when you create the variable it does not always propagate until you’ve restarted InstallShield. It’s a fairly consistent problem with Windows environment variables.)
  3. In Tools | Options on the Path Variables tab, make sure you have either “Always recommend…” or “Always display…” selected. If you want to use an environment variable that an existing path variable points to you will want to either modify/delete the existing path variable or have the option set to “Always display…”.
  4. Add or modify the location of a file in some part of the IDE and use the environment variable in the “Browse for File dialog”. This could be in a component or in something like the signing certificate file location in the Release settings.
  5. When the “Path Variable Recommendation” dialog appears make sure to select “Create a new path…” and enter a name that is identical to the environment variable you want to use.
  6. Go to the Path Variables section of the IDE and change the Type for the new variable to “Environment”.

If you did everything properly the “Current Value” field should immediately change to “” where “VARIABLENAME” is the name of the environment variable that you are referencing.

If someone knows of an easier way of doing this I’d love to hear about it!

Whittling away to nothing

I took some time at work today to give a pretty thorough run through to InstallShield 12 Professional. I have to say: I’m pretty annoyed. The last couple of releases under the new Macrovision brand have really been fairly telling about the focus of the parent company.

In particular with InstallShield 12 is the removal of the stand alone build engine from the Professional edition. Now it’s only available if I spend another $1199.00 to upgrade to the Premier edition. Unfortunately I actually make very good use of the stand alone build engine from InstallShield 11.5, 11, and 10 on several build boxes here at work. It has always been really nice to be able to test the automation scripts on my primary workstation and then port them over to a pure build environment with only a couple of tweaks and not have to worry about purchasing extra licenses for the application.

I suppose the upside is that there is really absolutely nothing except some IDE tweaks and long awaited bug fixes in 12 that really give me any reason to upgrade any of my existing projects. Without the stand along build engine I’m certainly going to be giving some thought to not migrating them at all.

However this is really starting to show a trend in recent InstallShield releases that we in the idustry should really be paying attention to. InstallShield X, while certainly having some flaws, was a really well done release that finally combined the entire sweep of InstallShield installation projects under one big suite of applications. You could build for any platform with pretty much a single app, and it worked. Just over a year later and Macrovision buys out InstallShield. The next release (10.5) is expectedly incremental, but still pretty good.

11 is the first full release under the Macrovision banner, and it’s pretty good. There are some interesting features added (The repository being my favorite. Too bad local repositories are still not entirely functional even in the current version!) and overall it’s a decent release.

Then came 11.5 which should have been just a point release, but somewhat unexpectedly they split up the Windows and Multiplatform camps into two seperate suites again. Those of us who were lucky enough to have a software maintenance plan got both versions but the letter that came along with it started to show that the Macrovision’s respect for it’s customers ended at the depth of their wallets.

Now comes 12, which really has very little in the way of substantial updates and they start to take away features? I think that might settle how badly they want the business of a shop like ours.

You know, WiX has been looking really stable lately and it won’t be a big deal to port some of my smaller InstallScript projects over to it. It will be nice to get some of those into MSI finally as well and there hasn’t been any really good reason to do it before now with InstallShield.

InstallShield 12

Macrovision released InstallShield 12 this morning, and my download of my maintenance fullfilment copy just finished. I’ve heard there were some big changes for the InstallScript language, hopefully for the better.

Update: I had heard slightly wrong, or at least read the commentary incorrectly. They changed the way that InstallScript custom actions interact with MSI packages. No big changes to InstallScript here…

About Me

My name is Nathan Stohlmann and I am a computer geek specializing in software build and deployment technologies and related engineering. Some might use the current hot buzzword “DevOps”. This is a skill set and focus that developed out of the 15 years that I’ve been using InstallShield, Wise, WiX, and various other products to design, build, and maintain scripted and Windows Installer based installation packages. Over time I took over the build automation for many of the products I was packaging and the logical next move was to do the end-to-end automation for the projects that did not require conventional installers as well. My current application expertise covers all of the installer specific tools already mentioned and also Ant, MSBuild, Powershell, TeamCity, uDeploy, C#, and a whole host of other things.

I am currently working for Pearson VUE and am relatively happy there. The shift of focus to general build and deployment has been a good one, and they do their best to make sure I know they want me around, but I sometimes wonder about what else is out there in this field.

I’m a fan of LEGO bricks and enjoy building with my modest (by some pretty odd standards) collection of parts. I am active in TwinLUG, a Twin Cities local LEGO User Group (LUG), and maintain the group’s web presence at twinlug.org. I once said I was primarily a Technic builder but over the past 6 years or so have spent most of my time working on contributions to Micropolis and maintain the official specification. I┬áhave also started another site, Virtual Micropolis, just to document me and my partner’s growing collection of modules.

I am an amateur musician. I formerly played Euphonium with the Calhoun-Isles Community Band and am trying to figure out how to add them or a different community band back into my schedule. I also sing Baritone with One Voice Mixed Chorus, a nationally recognized LGBTQA choir. You can also almost always find me at one or more TubaChristmas performances every year.

A note about spam that appears to have come from my domain, cavort.org. It appears that at least one spammer has been using various addresses @cavort.org as the purported sender of the messages. Please believe me when I say that if I could have that person in this room right now they would leave the room with an extremely funny walk. I do not send spam. This domain has never sent spam. It’s not me and I am terribly sorry if you got crap from those shmucks, but there is absolutely nothing that I can do about it at this point.

If you wish to contact me please use my first name at virtualmicropolis.com or through twitter.

Find me on Flickr!

Installscript Tip for the day:

While InstallShield’s Installscript does not have any String functions that can handle case sensitive comparison, the List functions do!