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!

Installations in Windows 8

If you follow my Twitter stream you’ll have noticed that I’ve been playing with the Developer Preview of Windows 8 this morning. I’ve gotten a couple of funny looks from the family but to me a new operating system to play with and especially one with as many interesting changes as Windows 8 is pretty exciting.

As an installation developer though I figured I’d take a quick peek at things and see what was going on at this stage. The short version is: Quite a lot and very little.

The big news for setup developers is the introduction of an entirely new distribution model for the Metro Style applications using an AppX package which according to the documentation is “An app package is a container based on the Open Packing Conventions (OPC) standard.”. So pretty much it’s a zip file with some structured content. There is API access to the installation system but for the most part as far as installation development goes for Metro Style apps: A person with my specialized skills is not needed. Honestly, that’s pretty much a good thing.

Of course this being a Microsoft product it does provide backward compatibility for older technologies and so I was unsurprised to see only a minor increment to the version of Windows Installer in this build to 5.0.8102.0 and continued to be unsurprised by the log output from a test installer I threw together to check for any non-obvious operational changes.

For your perusal:

The few little differences:

  • The USERNAME property in Windows 8 gets set to a generic “Windows User” instead of the username.
  • Even though the authored MSI does not have a LaunchConditions action in either the UI or Execute sequences it appears that Windows Installer on Windows 8 is attempting to run it anyway and gets an error.
  • A few small errors that appear to occur while attempting to update the progress dialog during execution.

At a guess the last two can probably be put down to defects of some sort, but the first one could be interesting if it is not another defect. The installer was executed under an account that was generated using my Windows Live ID so I generated a local user (Which can only be done through a currently non-obvious method) and verified that it shows up the same there. Though the USERNAME environment variable is populated properly so maybe this is just another defect. I know I have used that property for installations a couple of times and it would be problematic if it was no longer populated.

For completeness sake I also ran a couple of classic InstallScript installers and everything ran fine there as well and the log output from those didn’t have any surprises.

No tag for this post.

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…

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!