4 replies to this topic

[JustinCase1089]

We have been using InstallShield for many years and for our 2001 release we upgraded to ISD7.0. Here are our experiences so far.

We have around 15 products thet are deployed usign InstallShield. Around half of them are included in a single InstallShield and the rest of them are individual shields.

Migrating to the MSI architecture was quite a task and it is/was quite a challenge for the responsible to lean to dance with this elephant.

Finally 2001 was released. We now have several patches thet are our. Here is their status.

Product A, the big IS including many products. The patch was finally build after a lot of trial and error with undocumented error messages from different integrated programs in the patch generation. The files are not installed during patching though, for some obscure reason giving an error 1628, which we can't find any documentation on. Since there is no budget left to pursue this error all files that need to be patched will not either be zipped or patched in a 5.5 installshield, which is much less prone to obscure errors and I'm pretty sure will be a joy to work with in stead of ISD7.

Product B. A small product with around 30 mb of files. Patching went perfect, no problems, all files included. None of the files in a certain feature containing the main exe file are pached. The feature looks okay in Orca though. The patch now contaings files zipped in 3 different files that go to the different locations on the target system.

Product C. A bigger product with 100 mb files. The patch was succesfully created. The patch installs succesfully. Upon installation there are a lot of files left. We believe, that this is caused by the patch. Nevertheless the patch is released. Can't wait for the #### that hits the fan in SP2.

Product D. A product of 50 mb. Found out, that the patching needs Cache web installation enabled when doing a web build because the patch needs the original msi file. This was not default in ISD's and hidden well. Patch didn't work. We therefore rebuild a complete installation for the patch. Very ugly.

Product E. Patch build fine. Patch installed fine. Woohoo

So far there was something wrong with 3 out of 5 patchings.

We don't believe, that all these errors are caused by InstallShield alone. The MSI architecture is simply too stupid and requires too much from the user. Off course InstallShield doesn't make it better, since it is their job wrapping the stupidity in a user friendly environment.

In addition to this their service stinks. We had our money refunded, because they weren't able to answer our questions.

Unfortunately it seems like the competitor Wise for Windows doesn't do much of a better job wrapping MSI.

So what do we do?. I have even suggested building our own installation with freeware zip libraries. After all we are software developers, not full time MSI experts.

Best Regards
 Justin Case

[hambone]

i am sorry to hear about all of your difficulties.  it is a rather daunting task to embrace a new technology when documentation and qualified resources are scarce.  i must thank stephan for this forum to allow us to get together and assist each other with some of the issues...

i wouldn't blame any particular vendor ( well other then micro$oft, that is ) )  i think they are all doing the best they can ( although it would be nice to have a better conflict analysis and error resolution tool ).

i know this probably comes a bit late but i believe you will find that the 1628 error might be referring to an invalid table.  it is stated that these errors are returned by the MSIExec.EXE and InstMSI.EXE and others may be found in the WinError.h file.

i know the promise of the technology is to help end 'dll hell' but in my experience it has only transferred it to 'reg. hell' ( oh well out of sight out of mind )...

[Ben Woodcock]

For all you people who are thinking about writting your own install. I have.

And I will say that it is the best thing I could have ever done.

The install I do has to be able to install/upgrade no matter what is installed. (Our software interfaces with Quickbooks,ActiveSync,Hotsync,SPTHotsync,Broadbeam. To name a few).

I also needed to manage the software versions on multiple PDAs. None of which was ever going to happen through IS.

Now I have an install that doesn't take 2 minutes to start (what the hell is msiexec doing during this time). I can dsiplay what I want and where I want it.

Versioning is simple. The hardest part is the creation and deletion of shortcuts.

Ben

[Dave I]

I sympathise.

We had a relatively straightforward installation with InstallShield 5.5, fairly simple the majority of the department could understand and modify it.  

Now we have "Upgraded" to MSI, we need a 24hr install expert with the patience of a saint, and the and the jiggery-pokery skill to rival a voodoo witch doctor!

I working with MSI for 2 yrs, I hate to admit it but we should have written our own install software.

I know our workarounds are going to come back and haunt us when try to release future patches and upgrades, but I am resigned to fire-fighting rather that developing.

[bobv]

My experience with Developer 7 has been somewhat painful, but we have stuck with it and it seems to have stablized. Our first release with Dev 7 was about 12 months ago; second release 6 months ago. We were using IS 5.1 prior to using IS 7. We had been experiencing dll hell especially on the W2000 platform. This is what drove us to IS 7. IS 7 seems to have resolved the dll hell issue, but it certainly did introduce a number of issues dealing with Microsoft's Windows Installer API.

I have spent many hours trying to resolve why the install wouldn't run on a given system.  We have developed a box of tools and procedures to resolve the 1607 errors that our support people are using to resolve our customer install issues.
InstallShield's knowledge base on their website has been helpful, but it appears that was being developed while we were struggling to resolve these issues.

For the most part I was able to use the IS 5.1 setup.rul file with IS7, but it did include the changing of the system variables, e.g. TARGETDIR to INSTALLDIR. Our installers are use Installscript to a very large degree.

I have used IS7 to create a major upgrade, but have not used it to create a patch. Creating a patch seemed to be such a hassle in IS7 that I used IS 5.1 for the patches.

I am now evaluating IS 8. So far our IS 7 created installers have migrated without incident and are working without error.
I haven't tried the patch wizard in IS 8 yet, but I'm hopeful that it will substantially make creating patches easier.