I'm sure this topic has come up more than once, but I'm going to throw it out there...

I'm getting tired of using WinInstall LE 2003. And most of the packages I've worked on have been packaged w/ Wise and the like.

I'm relatively new in creating packages for distribution, so what would one recommend as software that is versitile but also easy to use?

0 Comments   [ + ] Show Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.


I could type the same for Installshield.

I just went through the procurement process for a software packaging tool for a large company and let the employees (all new to packaging) try out Wise and Installshield. I demoed both for them and gave them a little tutorial, then let them go on the tools.

They all thought Installshield was easier to get a grasp of.. its GUI is more "windows-y".

Wise's GUI is really ugly in my mind.

But once you are trained and using the tool for a few months, they're pretty much the same product with equivalent features.

In my opinion, what makes Installshield win is that it's cheaper with better support.
Answered 05/10/2006 by: turbokitty
Sixth Degree Black Belt

Please log in to comment
No offence! But its just a matter of being comfortable with the UI of the product that we use, in this regard I would prefer WISE.
Answered 05/11/2006 by: wiseapp
Second Degree Green Belt

Please log in to comment
Have to weigh in here in favor of WISE Studio in terms of UI/learning curve (Disclaimer: I haven't played around with InstallSheild for about a year --it might have significantly improved).

UI aside, WISE has one HUGE advantage over InstallShield that no feature set or improvement is likely to change: Installshield creates excellent PROPRIETARY INSTALLSHIELD MSIs. InstallShield MSIs depend on locally installing the InstallShield engine in order for the MSI and custom actions to run. I have also found that I.S.-built MSIs generally CANNOT be edited using any other tool and TRANSFORMS built using another tool also fail to work. Even worse, each MSI depends upon a SPECIFIC VERSION of the I.S. engine, which frequently changes along with the product version.

By contrast, WISE creates GENERIC MSIs that will run can be edited/modified/Transformed using ANY MSI TOOL (ORCA, WinInstall LE, etc.). No comparison which tool is more flexible and less proprietary IMO.
Answered 05/12/2006 by: norexx
Orange Belt

Please log in to comment
Norexx, this latest post only proves that you know nothing about Installshield. If you only know Wise, only comment on Wise.

Installshield only creates MSI's (setup.exe's really) that require the ISSCRIPT driver when you put in CA's that use ISScript. You can make "generic" MSI's in Installshield, and in fact the majority are "generic". I've coded hundreds of MSI's and MST's in Installshield and I've never once used ISScript. I only use VB/WSH for CA's.

I've used both products in shops that only have Wise or Installshield and have packaged extensively with both. I feel that the products are largely the same. Just a preference thing with the GUI that can be sorted out by downloading both demo's and trying them out for an afternoon.
Answered 05/15/2006 by: turbokitty
Sixth Degree Black Belt

Please log in to comment
In defence of norexx, I think his/her post is very well thought out.

I have been repackaging for a few years now and I continually get p**sed off with InstallShield so-called MSIs. Admittedly I didn't know that Installshield gave the option of creating a generic msi, but based on my experience, neither do the majority of software developers / package developers.

(My personal opinion here) Look at pretty much any Windows XP machine and you will find the InstallShield engine installed. Why?! The Windows Installer service provides most of the functionality needed to install software. Anything that Windows Installer can't do can be covered by using a custom action. The Installshield engine is totally unnecessary, except of cource for justifying the existence of Installshield!!!

I've even come across a quite nasty InstallShield engine installs which, upon installation, DELETE the Windows Installer registry information related to the ISScript engine install, thus making it impossible to remove without going into the file system and registry. From a desktop management point of view, this is really crappy behaviour.

(OK rant over)

I primarily package with Wise, although I think with v6 they have been getting a bit cocky lately. Sometimes their Windows Installer Editor tries to be too 'helpful' - it's getting quicker to do some tasks with Orca directly.

My advice - use Wise or Installshield depending on your preference, but PLEASE, PLEASE, PLEASE create generic MSIs that do not have dependancies on anything other than the Windows Installer service. In that, turbokitty, I applaud you for knowing how to avoid reliance on ISScript.
Answered 05/15/2006 by: Bugbear.1973
Yellow Belt

Please log in to comment
Well, in the interest of closure, there is a history behind Installshield's use of ISScript.

Back in the day, pre-Windows Installer and WSH, developers needed a way to install their applications on their customers' PC's. Installshield developed InstallScript, a scripting language that required a runtime to achieve its many robust functions. It worked very well, so well in fact, that almost all developers were using it. It quickly owned the market place.

Enter Microsoft (always late to the party) with Windows Installer. Basically just a runtime that's built into the operating system. Installshield adapted to the new format but you couldn't expect all those developers to learn MSI over-night, so they included ISScript functionality in their MSI creator.

That's where we are now.

You can't blame Installshield for that and you can't blame them for a developer writing crappy ISScript code. That's like blaming Microsoft for a crappy VBScript. However, feel free to blame Installshield for their buggy code, blame them for their stupid "Program Update" service, etc...

Installscript isn't required at all to make an MSI in their product, no more than Wisescript is needed in Wise.

Just setting the record straight.
Answered 05/16/2006 by: turbokitty
Sixth Degree Black Belt

Please log in to comment
Okay, I'm a newbie jumping in late to this string with a question that I'm sure betrays the wetness behind my ears but:
Given that in my company we have only XP workstations, all of which have some version of ISScript Runtime on them (mostly ver.3, with some PCs having 8, 10 or 11), and given that I use Macrovision's products to do my packaging (mostly MSTs and simple MSIs for in-house apps and the occasional repackage of legacy apps) - have I possibly been building and deploying MSIs with ISScript dependencies built-in? How do I know whether I've built a generic MSI or not? Cuz I'm not too clear on what ramifications there would be should we try to do an across-the-board upgrade of our ISScript Runtime version or maybe retire its use all toghether some time down the road, but reading this string of posts has me wondering and you all seem to know your stuff way better than I.
Answered 05/25/2006 by: fosteky
Purple Belt

Please log in to comment
No worries Kyle, to make use of IISScript, you would need to do so consciously. Unless you are developer savvy in InstallShield script- and knew to make use of it, it is not used. The paranoia you hear regarding this is largely from people who have not used AdminStudio. If you really want to make yourself comfortable that you have not magically taken on this dependency, just double-click on the MSI directly and if it did require InstallShield script you would get a message box explaining that you must launch the installation from a setup.exe and cannot run the MSI directly. This is regardless of if you have the engine installed on your computer or not (which is why admins hate these MSIs so much!).
Answered 05/25/2006 by: bkelly
Red Belt

Please log in to comment
Personally, I've found more support on the internet for Wise Package Studio than Admin Studio. That being said, as long as you are making MSIs the tool is irrelevant since the MSI is simply a database to be read by Windows Installer. You should try both tools and choose the one you feel most comfortable with.
Answered 05/26/2006 by: xythex
Orange Senior Belt

Please log in to comment
We're finding the isscript driver very difficult, and seems to be needed on every new version of software that comes in now. Any general guidelines for dealing with the ISScript:

1) Do you need a certain version of isscript for a given msi, or will the latest isscript driver (11?) work for all? If you need a specific version for a given msi, how do you know which one is the right one?

2) I've seen several instances of the isscript screw up registry rights for the user installing via SMS2003 (because SMS uses the local admin account), leaving a bad install for the user. Any ways to avoid this, without having to hack the reg. for each script?

Answered 05/26/2006 by: markergj
Yellow Belt

Please log in to comment
1) They are backward compatible in most cases. Although I'd test your deployment with the old version first before pushing it out.

That said, in most cases I'll just repackage the app into pure MSI.

2) Not sure about that one. If you're encountering issues, just repackage the app.
Answered 05/29/2006 by: turbokitty
Sixth Degree Black Belt

Please log in to comment
2) I've seen several instances of the isscript screw up registry rights for the user installing via SMS2003 (because SMS uses the local admin account), leaving a bad install for the user. Any ways to avoid this, without having to hack the reg. for each script?

Yep - this sounds like the problem I had the other day... the cause is down to the permissions set in the DCOM Config for the InstallShield Driver - shows up as a 1603 error in the install log.

Installing the MSI manually logged on as local admin was fine but via SMS it kept saying that admin rights are required...

I had to add a CA to my package to fix the reg early in the install routine to get the package working via SMS. The other option was to customise the ISS10 prereq MSI to fix the permissions but wasn't sure what effect that might have on other packages in the future which need ISS10 - so not ideal.

More info here: http://itninja.com/question/what-is-pxe?6

Hope it helps,
Answered 05/31/2006 by: MSIPackager
Third Degree Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity