Software Deployment

Please help me 2 find out the differnces. So tht I can suggest our clients 2 go for Wise instead of Installshield.

In my opinion Wise is a considerably better product. However you internal usage may dictate IS as more suitable for your environment.

Wise have a considerably more indepth knowledge of how windows installer works in relation to COM registry and self healing. As such Wise produces a considerably better package than that of Installshield.

So in order to answer your question correctly we need to know how you intend to use the product ?

Repackaging or Authoring new apps ?

Some things to compare against.

Wise bundles COM registry into the same component as the COM server. (exe or dll) this is a huge advantage in terms of corporate deployment solutions. This means that reference counting is supported correctly and makes the application more sociable with other applications.

Installshield puts all HKCR entries into a single component and to ensure it doesnt break anything it marks the component as permanent. This means that HKCR is not uninstall during uninstall.

Wise uses correct directory references when authoring paths into the app.

For example a path such as c:\program files\MyApp\ should be written as something like [INSTALLDIR] wise makes correct use of this. Installshield does things like this

[ProgramFilesFolder]Folder\myApp.exe

This in effect means that the application is not dynamic, therefore if you move ini files or registry information paths stay hard coded to the old locations prior to moves. This in my opinion is simply poorly developed code.

Wise validation modules are linked to the Editor. This means that you can double click on validation errors and get taken directly to the table of choice.

Wise has support for virtual packaging which is useful as enterprise deployment.

Wise has packaging script support
Installshield has deployment script support

The difference being that Wise aids a packager at packaging time, where as Installshield makes deploying complex items easier for the packager often resulting in a headache for the people deploying the application as installshield script has a dependancy on a scripting engine be deployed prior to the main app. This is also riddled with bugs.

Installshield does not allow use of the project sequencer when repackaging so if your a repackager this means you cannot structure your team to work in identical formats. ( I have written an add on to make this work if your interested, not that it should be required)

Installshield has a better custom action interface than Wise (if your unfamiliar with windows installer technlogies)

both have relatively intuitive interfaces

Installshield does not take into account how self healing works when repackaging and as such completely screws up the feature structure in terms of self healing

Wise makes use of the feature structure to build a structure which supports the fastest method of self healing.

the shortcut menu in Installshield is a little stupid if your trying to work out where your shortcuts are. Its easier to add shortcuts however if you know where you want them to go.

Installshield's conflict manager (on the versions I looked at) do not show component GUID's. Conflict management is about matching component GUID's if you cant see them how are you supposed to know if its right ???

In my opinion Wise is more mature as a product and creates an internally better application when capturing.

All this aside I have not looked at newer versions of IS but I think they really just dont understand the underlying fundamental Windows Installer well enough to improve the product any more than it currently is.

The AMS product from Installshield is considerably better than the same thing from Wise.

I am not working for either company and this is a completely independant assessment I simply believe Wise to be better.

John

Hi John, Thnx a lot for the info:)
Do v have any option 2 capture the hardware registry entries in Installshield?
In wise, we have an option in the setup capture configuration.
How abt capturing device driver appln in installshield?
Can anyone help me on this?

---------
Sharon

when capturing drivers your better of using DPINST of DIFXAPP as custom actions to install the driver.

Installshield can capture hardware registry but as far as I am aware you cannot switch it on and off like you can with wise.

from a capture perspective wise is considerably more flexible than installshield, note I am basing my opinion of installshield from version 6.5 which was the last one I used. I believe they are now up to 8.5 but the product hasnt really changed much over the years so I am not expecting a dramatic improvement.

Um.. pretty much everything jmcfadyen posted about Installshield is not actually true. I could go through it line by line, but I can't be bothered.

There are many posts on this board debating Wise vs Installshield. I suggest you use the search forum instead of relying on a post from someone that doesn't know how to use Installshield. No offense jmcfadyen.

no offence taken turbokitty,

thats why i suggested seeking others advice as well.

but I am more than happy for you to explain exactly what it is that you think I may be dping wrong so that I can avoid these things in the future.

particularly in relation to CMDB and executing the project task list from a packaging machine I have asked these questions many times over the years in here and never had a response so your assistance would be great !

Wise bundles COM registry into the same component as the COM server. (exe or dll) this is a huge advantage in terms of corporate deployment solutions. This means that reference counting is supported correctly and makes the application more sociable with other applications.

Installshield puts all HKCR entries into a single component and to ensure it doesnt break anything it marks the component as permanent. This means that HKCR is not uninstall during uninstall.

The above is true but ONLY under certain conditions. Those conditions are if InstallShield, during the compile of your re-package, is unable to cross reference correctly the COM information it finds, if a progID is lowercase in the class table but uppercase in the progID table it will dump it all into HKCR, this is by design.

I would personally prefer to know about these type of problems than just have it done for me with potential problems but to be honest it is usually down to bad coding by developers and nothing to do with IS.

Each tool has its plusses and minuses and you will get comfortable with tweaking working around the various faults of each product.

Paul

ORIGINAL: jmcfadyen

Wise have a considerably more indepth knowledge of how windows installer works in relation to COM registry and self healing. As such Wise produces a considerably better package than that of Installshield.
ohn



I believe this was covered.

ORIGINAL: jmcfadyen
Wise uses correct directory references when authoring paths into the app.

For example a path such as c:\program files\MyApp\ should be written as something like [INSTALLDIR] wise makes correct use of this. Installshield does things like this



Installshield also uses INSTALLDIR. It also has the option of showing you real paths in the GUI if you wish. It also has dynamic source directories for build time.

ORIGINAL: jmcfadyen

Wise validation modules are linked to the Editor. This means that you can double click on validation errors and get taken directly to the table of choice.


The validation report will point to the offending component as well as provide a link to the Installshield site with technotes on what the error actually means.

ORIGINAL: jmcfadyen

Wise has support for virtual packaging which is useful as enterprise deployment.



If you're referring to Altiris virtual packages, then yes, Altiris owns Wise, so yes, that's true. It's only useful if you're using Altiris.

ORIGINAL: jmcfadyen
Wise has packaging script support
Installshield has deployment script support


I have no idea what you mean by that.

ORIGINAL: jmcfadyen
The difference being that Wise aids a packager at packaging time, where as Installshield makes deploying complex items easier for the packager often resulting in a headache for the people deploying the application as installshield script has a dependancy on a scripting engine be deployed prior to the main app. This is also riddled with bugs.


This arguement always annoys me. ISScript is OPTIONAL. When used, it will require the compiler at runtime. But that's precisely why Installshield tells you not to use it. It's only there for legacy support as it was the installation engine of choice prior to MSI.

ORIGINAL: jmcfadyen

Installshield does not allow use of the project sequencer when repackaging so if your a repackager this means you cannot structure your team to work in identical formats. ( I have written an add on to make this work if your interested, not that it should be required)


Installshield does have a workflow interface. It also has an enterprise workflow server add-on that's far surperior to anything Wise is offering. It's useful for very large organizations with packagers in different geographical locations.

ORIGINAL: jmcfadyen
Installshield has a better custom action interface than Wise (if your unfamiliar with windows installer technlogies)


This is true. Wise is terrible at custom actions.

ORIGINAL: jmcfadyen
Installshield does not take into account how self healing works when repackaging and as such completely screws up the feature structure in terms of self healing

Wise makes use of the feature structure to build a structure which supports the fastest method of self healing.


I'm not sure what you mean here. You may be right, I'm just not sure what you're driving at.

ORIGINAL: jmcfadyen
the shortcut menu in Installshield is a little stupid if your trying to work out where your shortcuts are. Its easier to add shortcuts however if you know where you want them to go.


I'm not a fan of the shortcut interface either. I use the setup design view for shortcuts.

ORIGINAL: jmcfadyen
Installshield's conflict manager (on the versions I looked at) do not show component GUID's. Conflict management is about matching component GUID's if you cant see them how are you supposed to know if its right ???


This isn't true. At least, it isn't anymore.

ORIGINAL: jmcfadyen
All this aside I have not looked at newer versions of IS but I think they really just dont understand the underlying fundamental Windows Installer well enough to improve the product any more than it currently is.


I believe you said you worked on Installshield "DevStudio". That was several versions ago.

I would again direct people to the "search" function. This topic comes up about once a month so there's lots information pro/con already documented.

I will boil it down for you though:

Wise:
Better at some things

Installshield:
Better at others

Both:
Pretty much the same.

Pick the product you already have some in-house knowledge with, or pick on price.

I would argue that not understanding why a feature tree looks the way it does wouldnt help anyone. As someone who does understand how feature repair works I would much rather prepare my own feature tree than have a half arse job done by the program I use.

It comes down to how much do you automate something for the packaging n00bs out there, if the program does it all and a problem arrises, not understanding why it does because the program did it doesnt help anyone.

Again, it comes back to choice, use what your confortable using, they both do the same thing but at the end of the day its the packager who makes a package work, not Wise or Installshield and if you think that Wise or IS do make a package work then your in the wrong job :)

Paul

PS, by work I mean leverage all the MSI capabilities and not just some shoddy MSI full of ICE errors and warnings!

jmcfadyen,
Again, i'm nto really following you. You can write to ini files and registry however you like. With properties referencing paths or hardcoded values, or the [ProgramFiles] abbreviated method.
[ProgramFilesFolder] is a directory variable name that resolves to Windows' program files folder location on the target machine. You're saying you'd prefer if the entire path to the folder had its own variable name? I don't really see how that's more beneficial. If the target machine's program files folder is in a non-standard location, it will properly adjust the install location with this method.

I think this comes down to the same thing as the feature healing. You can have the GUI hide and dumb down things for you or you can write them out properly and actually pass logo testing.

As for the workflow tool that's bundled with the base AdminStudio package (not the server extension), it can be viewed from the AdminStudio main GUI panel. When opened, switch to the "Workflow Templates" tab.

I've contracted using both Wise and AdminStudio. As I stated earlier, there is little difference between the two in the end. I always purchase AdminStudio for my clients because it's cheaper, the phone support is better, and it has a more intuitive interface. The last point is my personal opinion, the first two are fact.

turbokitty,

in relation to the paths it has considerable difference by utilising an individual path variable vs [ProgramFilesFolder]

For example lets assume the path was an inprocsvr32 key for a registered dll.

If you use

[ProgramFilesFolder]folder\myComServer.dll

vs
[FolderName]myComServer.dll

You have a situation where if for some reason the file is moved all of the paths that reference the [ProgramFilesFolder] variable will remain pointing at the same location. Therefore you are in a situation where you now have two different path references.

By utilising [FolderName]myComServer.dll if you move the file for any reason then all of the associated items also change paths dynamically.

One may argue if you get the package right in the first place its not a problem. I have seen it cause issues in the past and its quite difficult to troubleshoot.

Having used both in anger they both have plus\minus points when packaging\capturing\solving,

Wise isnt a resource hog and also seems to have less bugs.

I agree with Tone,

Wise seems to have less anoying bugs (although there are still a few!) and maybe I noticed less because I've been working somewhat more with InstallShield.

InstallShield only seems to worry about new features that aren't of any interest to people who are repackagers. Instead of solving bugs which have been in there for quite some time now.

If you are a serious repackager, prepare to write some scripts that clean up and solve bugs just after a snapshot. Both tools have issues and you dont want to fix them by hand. (sorry won't share those scripts).

can you please let me know what the scripts do atleast? It would really help me.

i agree with many comments both do the job

I forgot to mention Wise does screw up the implementation of merge modules very badly.

- My scripts will check for instance for Darwin descriptors (which will be there when repackaging native MSI (I have my reasons :) )

- Multi string registry values will be checked in the snapshot, since this will sometimes generate incorrect values.

- GUID's will be made upper case (other wise they won't be associated with the correct executable --> Class tables etc.)

- Kernel / File services will be modified into custom actions (sc.exe)

One of our developers is busy creating a tool which does all these actions (and a lot more). This tool will fix certain errors which occur during the capture of Wise or InstallShield. Because this tool will become available commercially, I won't be able to specify all the items that it fixes.

I'm sorry I can't go into detail of all the functions, but I hope you still get the idea.

turbokitty,

I think you missed what I was getting at here.

Installshield also uses INSTALLDIR. It also has the option of showing you real paths in the GUI if you wish. It also has dynamic source directories for build time.

I understand installshield uses INSTALLDIR but what I mean is that it writes paths into ini files and registry such as

[ProgramFilesFolder]FolderName\SecondFoldername\filename.exe

Where in fact it should be written as

[DIRECTORYVARIABLENAME]filename.exe

Installshield does have a workflow interface. It also has an enterprise workflow server add-on that's far surperior to anything Wise is offering. It's useful for very large organizations with packagers in different geographical locations.

This one I am particularly interested in. I have been trying to work this out for a long time and no one has been able to provide a resolve to this in the past so I would be very happy to know of your solution. How can you access the workflow during a repackaging scenario. From what I have tested this is only available when the full IDE is deployed I would like access to workflow without IDE installed. As for the AMS add-on I already mentioned that was far better than the Wise equivalent.

I'm not sure what you mean here. You may be right, I'm just not sure what you're driving at.


I was referring to the way wise leverages the Feature Level healing versus component level healing. For example the creation of

complete
- feature1
- feature2 etc

the items in Feature1 and 2 are advertised meaning that accessing that feature would set the healing level to feature level. As their is only 1 component in the feature only a single component is marked for feature level healing. This in turn means that the remaining application will be healed at component level.

Mainly only assists with speed of healing etc