InstallAware

Hi, I'm a user of InstallShield Express since many years.
The last days I've evaluated InstallAware Express 6.0 Build 060606 and Developer.
For the evaluation results please see my other posting (2).

I run into a couple of problems which I was not able to solve.
Maybe I was doing something wrong:

1. The biggest showstopper for the Express version is the handling of features.
If I create a feature and later delete it, the web media blocks and the referenced files are not removed.
This can easily mess-up the whole project. This can only be fixed by editing the script (not possible for Express).

2. I created a small .NET 1.1 project. If I install from a web based setup I can modify/repair/patch my setup.
If I install the exact same project from an uncompressed setup then do a modify/repair, the installer asks for the location of the previous .msi file.
What happens here?

3. I installed some assemblies in a directory via the assemby installer, then I create an updated version and a patch.
The patch doesn't updated the assembly files.

4. I tried the update feature. I was logged in as DOMAIN\\administrator but the updater (scheduler)
was created for the MACHINE\\administrator which never logged in. So I never got any update notification.

Martin -

1. Empty web media blocks in the script have no effect. You can always delete files in the Files view.

2. Naturally, when you are doing a modify/repair, setup must have access to the original setup CD, so it can copy files.

3. Did the assembly versions change?

4. You can schedule the task for the domain admin, but this will need scripting access.

Thanks for the reply Michael.

MichaelNesmith wrote:1. Empty web media blocks in the script have no effect. You can always delete files in the Files view.

Ok, I verified this. I assumed that deleting a feature automatically deletes the files inside.
I created a feature, deleted it (because in Express there's no way to move a feature in the hierarchie)
added it again and added files again. Later I got runtime errors in the installer (couldn't create regkey for feature...).
Then I detected the many Web media blocks and tried to get rid of them. I think that this feature can be improved.

2. Naturally, when you are doing a modify/repair, setup must have access to the original setup CD, so it can copy files.

Sure, but I installed from my harddisk (uncompressed setup). The path hasn't changed.
I thought that windows installer is caching the msi. And a web setup was working.
So I still think there's something wrong.

3. Did the assembly versions change?

Yes, the build number changed from 0.9.2354 to 0.9.2361.

MichaelNesmith wrote:4. You can schedule the task for the domain admin, but this will need scripting access.

What is the reason, that the logged in user (who runs the setup) is not used?
I noticed that IA itself scheduled my domain login.

1. You're probably right - your solution would be use Developer or above, I'm afraid.

2. Nothing is wrong with this part. You need to point setup at the source when you are doing a maintenance or repair. Web builds don't have this problem because they locally cache their source.

3. I'll report this as a possible issue.

4. This is very strange, as InstallAware's own setup itself uses the same update script that Express ships with...

2. Nothing is wrong with this part. You need to point setup at the source when you are doing a maintenance or repair. Web builds don't have this problem because they locally cache their source.

I haven't seen this behaviour with any other product. I can modify/repair
as long as the source is available in the previous path. This is very
annoying. Why don't you do it in the same way as a web setup?

I then tried to modify my IA installation. I installed from the single
file download. The setup wanted me to locate my setup sources. I selected
the folder with the InstallAware_6_SFX.exe. The dialog popped up again and again.
This is not working! I consider this as a showstopper. Please investigate.

4. This is very strange, as InstallAware's own setup itself uses the same update script that Express ships with...

I'll create another setup today and verify this again.

Two more issue:

5. The web media blocks are automatically created with an URL in mixed case,
e.g. Microsoft MDAC Refresh 2.8.7zip but IA creates a file in all lowercase,
e.g. microsoft mdac refresh 2.8.7zip.

If I copy this file on a Unix based web server, the download fails. This is
not a big issue, but time consuming and error-prone.
IA should either create the URL in lower case or create output files in the
same case as defined in the web media block.

6. I created my setup as a user without administrative rights. Everything
was working until I used the Refactor Paths dialog. I modified the
assembly files path and clicked on the assembly view. I got an .NET 2.0
exception in mGacUtilX and was caught in an endless loop. See attached screen shot.

File Attached:

bug.gif

The problem with the update schedule arises because the IA script does not
include the domain name for the user. If you add a scheduled task (via
control panel/scheduled tasks/Add scheduled task) you will see that Windows
adds the domain name to the user name.

The IA update script only uses the user name. If I'm domain administrator
Windows adds the local machine name because the user administrator is
present. If I'm logged in as domain user my user name is not present on the
local machine and the domain name is used.

This should be easily fixed.

Please review the help file section on the different build types. When and where sources are required is very clearly documented in the help files, along with the reasons why. If you want guaranteed source resolution all the time (which is something you do not get with other tools), restrict yourself to using web builds. You have a choice with InstallAware. If you use web builds with a single Offline Content web media block directive, you will obtain what you need.

Thanks for your investigation of the domain issue - I'll go ahead and pass it up the chain.

MichaelNesmith wrote:Please review the help file section on the different build types. When and where sources are required is very clearly documented in the help files, along with the reasons why.

Michael, can you point me to the index entry your are referring here? I
only found the deployment entry which doesn't document this restriction.

But once again: You didn't answered my question about the unability to
modify the setup after downloading InstallAware_6_SFX.exe. What is a
compressed setup good for if I can only install/uninstall but not
repair/modify?
Please install from the compressed InstallAware_6_SFX.exe and try to
modify the setup afterwards. Is this behaviour intended?

The help states, that an uncompressed setup is best suited for CD-ROM
distribution. Agreed. But here again I think that an average user is
overstrained with this type of dialog asking for the source if the CD-ROM
is already present. I have never seen this with any other MSI based installation.

Most annoying on this dialog is the fact, that I can't cut'n paste the path
into. I always have to select each directory level and don't get any default
(seems to be a dialog of IA not Windows Installer).

I really like the advantages of IA and in the meantime I'm willing to buy
the Studio Edition if these problems are solved.

P.S. Have you had a look at issue 5. and 6.?

Hi Martin!

The help file section is titled: "Deployment". Also read the Source Resolution subheading under "Patching", which explains the problem you've been having with the single file build - yes, its intentional.

I've passed the rest on for further feedback from the product team.

I've passed the rest on for further feedback from the product team.

And what does the product team thinks about this?

Hi Michael,

I also agree with Martin suggestion and complains about the source file not being able to be found. As a matter of fact I am evaluating IA 6.0 and in my first patch build I was faced with the Browse For Folder dialog which and I was not able to tell where was the location of the original setup, since I installed from a compressed file MySetup.EXE and pointed to the folder where this file was and still the patch was not able to find whatever source it needs.

I admit I have not experience with Windows Installer (which is why I want to go with IA ) but as a developer and having installed many applications, when installed from a hard drive and then modify a feature I was never asked for the original source files and I expect the same functionaly from my IA setups.

I just did a test with an installation package for Diskeeper created with InstallShield which consist of one compressed file, then I downloaded an update single file and did the following:

1.- Installed the main program from a USB Drive.
2.- Copied the update file to the Desktop
3.- Removed the USB Drive from the computer
4.- Ran the update file and it just completed the update to the main program.
This is the kind of result I want my setups to have, as simple as possible for the end user which does not knows anything else other than double click the files I send them

I've passed the rest on for further feedback from the product team.

I also would like to know the feedback.

Thanks!

Hi Michael,

After reading the Patching topic of the help file, I found this note:

Because this is a largely inconvenient way for end-users to apply a patch, Compressed Builds are not recommended as the targets of patches.

I most likely will always use Compressed Builds, what will be the recommended IA procedure to update my installations?

Thanks!

This is not only an issue with InstallAware. It will be an issue with any Windows Installer tool that you use. Windows Installer simply requires access to the original setup sources when you are patching. The only other alternative is to include whole files as patches, which you can configure in the Project Options dialog. However, this loses the benefit of incremental byte level patching.

Now, on top of this default inconvenience that you get with Windows Installer for "free", InstallAware does provide a better solution: web builds. Because web builds always locally cache their content, end-users will never be prompted for setup sources. This is a unique benefit of InstallAware among other MSI tools.

If you want to ship a monolithic file that contains everything, you may still do so using web builds. Just take out all web media block statements, and insert an Offline Web Media Block command all the way on top of your script (a web media block with an empty name). This will essentially be a compressed build, with the sources locally cached.

Hi Michael,

using Web Media Blocks for online delivery is ok.

But for an uncompressed CD-ROM distribution any other windows installer based tool does
not ask for the source when I do a modify/repair as long as the source is available.

I think that this can be easily fixed because the source path is already stored in the registry.
The runtime setup engine only needs to get the path, verify the source and if missing complain.