Software Deployment

ORIGINAL: cannear

Thank you all for the informative feedback, this provides the background information that I needed.

On the same topic, I have been informed that using Installshield (versus Wise) will reduce the effort (time) to develop MSIs. Case in point, on previous projects (1000+ apps) we have found that "on average" it takes 5 days to create, test and QA a repackaged MSI or create, test, QA a MST. I have been told that this effort would be significantly reduced to 1 day, if Installshield Admin Studio is the primary development tool used for packaging / repackaging.

Having had little experience working with Installshield on previous projects, I'm not in a position to either support or contest this statement.

Any clarification would be appreciated!


That is so not true...

Installshield does not reduce effort time to develop MSI's. In fact it is usually slower than Wise.
You can do a simple test by using the evaluation versions of Wise and Installshield :
Try to work with an MSI that has lots of entries in the registry or file table (5000 or more...)
You will see that everytime you access the table Installshield will reload the table into the memory and the waiting times are bigger than with Wise. When it comes to work with big packages Wise is a lot faster then Installshield.

I work for 3 years now in the software repackaging industry and i use both packaging tools, depending on the project requirements. I think that Wise is a 'little' bit better, at least for my needs.
Both tools have their advantages and list of bugs... For example Installshield makes better setup captures in some situations while Wise is faster when it comes to working with big packages.

Regarding the compatibility issues between Installshield and Wise... i had a few. There were some cases where we could not make transforms to Installshield MSI's using Wise. So we had to use Installshield or ORCA (it is free and very very good) to make those transforms.
We never had the reverse problem though.

I think the decission of buying one of the two products depends more on the license costs and not the productivity. You can do the same stuff in almost the same amount of time with both.
And to be sure that you get your work done... download ORCA and use it 'when the going gets tough'.

Hi Jim,

I'm going to precede what I say with great respect for the effort you have put into this community into answering questions and being involved in fixing problems, and educating people, and also to your experience in repackaging...

But to see a moderator of a forum continually stating information that is totally incorrect, when you've been corrected multiple times, is somewhat disturbing. Especially when its a newcomer asking for advice as to which packaging tool to purchase. We've been over this before, but statements like:

Wise makes MSI's
Installshield makes Installshield MSI's

And there is a difference!

Wise does not put down its own engine to enhance The Windows Installer service but Installshield does and there in lies the difference between them.

And

Installshield is bastardising a standard simple as that.


Are misleading at best, and blatantly incorrect at worst. I would rather say:


Wise makes MSI's
Installshield can make MSI's or can deilver MSI's with its own scripting engine, at the choice of the MSI creator.

Wise does not put down its own engine to enhance The Windows Installer service, Installshield can use its own scripting engine but does not force you to.

Also, you better watch out for future features of Windows Installer, Tyler Robinson, one of the lead developers on the Windows Installer Team used to work for ... Installshield!

Just to reiterate a simple point on this: while developers “may” (to our dismay) make use of InstallShield Script, there is absolutely no reason for any administrator creating packages to ever use it. It is not required or used by default and is not a consideration from the perspective of a repackager.

ORIGINAL: kkaminsk
The one thing that does catch my interest is Devstudio 6 has facilities to make pure MSIs out of InstallScript.


Well maybe ... maybe not. We use Installshield Admin Studio 6 at work. I used "Installation Monitoring" on Sybase PowerDesigner 11, which is an InstallScript 7 build. The results were terrible. ICE errors out the Yin-Yang, custom actions calling obscure dll functions with who knows what intent, weird run-time requirements for a dll not evident anywhere, incorrect paths, bad shortcuts, it was h*ll.

I wasted 6 working days on that before tossing it in the bin and doing it from scratch with a traditional 2-step snapshot. Which worked like a charm and gave me a nice clean result that needed massaging only around the dynatext configuration for on-line docs.

Moral of the story - if it sounds too good to be true, maybe it is....

Regards,
William

ORIGINAL: bkelly

While Wise has been known to have some trouble creating transforms of some InstallShield MSI setups, I think this is a matter of InstallShield's decision not to share proprietary information on the matter. I have heard of no (and have encountered nothing) to support the fact that either company has done anything to make repackaging their competitors applications more difficult or troublesome. I've had dealings with both vendors and use both products regularly.

Given the very nature of the delta/snapshot or process monitoring features that dictate the contents of a package, it stands to reason that the "repackaging" aspect of Wise and InstallShield (as well as Prism, ZenWorks, WinInstall, etc.) are fairly equal in what they would generate for a package. While exclusion lists and other differences could be a factor, I would say that generally speaking it is the additional tools, wizards and processes that these tools deliver that helps them to stand apart.

I am talking your question of repackaging an MSI to mean you want to repackage a legacy setup into an MSI package. If you are referring to actually repackaging a setup that is already in MSI format, then I agree completely with cdupuis - don't do it!


I have to agree with Bob here....the only difference I have EVER noted between these two tools is the fact that Installshield must install the ISScript engine as part of its install. This allows packagers more flexiblily in packaging apps.....but it does deviate away from the MS standard. WPS uses its own script as well but has zero footprint to do it.

I also agree with cdupuis....a vendor msi should not be repackaged UNLESS you have extremely strict guidelines that prohibit the use of vendor msi's natively. I currently work for such an organisation but I can say they are not common and unless the company is prepared to throw enormous amounts of money around to stick to the guidelines....then destribute the vendor package as is.

On a side note: What really drives me nuts about these SLAs is that they are trying to jam technically complex work that is pretty much a desktop architecture role into an assembly line. I find too many shops trying to ramp their productivity up and just end up causing quality control issues through unforseen integration issues once everything hits production or just plain bad change control. I just recently saw an energy company a couple million of dollars via end user downtime because a critical application deployment was mismanaged.

Like everything in IT, pay now or pay later.

</RANT>

Good practice would suggest that you do not repackage a vendor supplied MSI. There are documents out there that specifically state that you can modify any and every option via a transform file. Now keep in mind that it is quite complex and advanced to transform some Vendor supplied MSI files that have been developed without the thought of administrators that would be looking to apply a transform file to it. Since I have purchased Admin Studio 5.5, I have had a great ease in creating transform files for at least 90% of the applications (in native msi format) that I would have previously tried to repackage.

To add, I did an in depth evaluation on Wise Package Studio, Installshield Admin Studio and New Boundary Prism Deploy. I found that I was able to do some things that I could not with Wise and same for Installshield and so on. My manager informed me of the budget available and since we are public sector, we could not have both (or all three). I decided on Admin Studio for the sole fact that it is the easiest and most full featured of the three. I find times where it would be great to have the three products as I find myself in situations where it would be faster to have a different product. But take into mind the Total Cost of Ownership... The TCO of having 2 or three different apps, may save enough man hours to pay for itself over a 1 or 2 year period. By purchasing Installshield and using it over the free Wininstall LE repackager available on the Windows 2000 CD, I have saved quite honestly weeks of my own time. In conjunction with that, we also purchased VMWare (virtual machine software) so we did not have to spend countless hour reimaging machines to do test installs of our final products. Our repackaging efforts which used to be stretched across three people can now be done by myself in 1/3 of the time. If anything, maybe toss the idea of VMWare the way of your sys admins, they may agree that one repackager and that is enough, and it is a bonus to management as VMWare is 1/3 the cost of any of those avaialble products. If you would like any other questions answered, please feel free to email me directly. Also, they may want to get in touch with Bob Kelly (he runs this site) as he also has a nice product available to scan repackaged and vendor supplied MSI files for errors and give enough information to clean them up. The program is called PackageCleaner and is advertised all over this site. He can arrange a a demo for you. I have had a chance to look at the product myself and I really think it is great product, Bob has also been very helpful in my ongoing evaluation of it.

While Wise has been known to have some trouble creating transforms of some InstallShield MSI setups, I think this is a matter of InstallShield's decision not to share proprietary information on the matter. I have heard of no (and have encountered nothing) to support the fact that either company has done anything to make repackaging their competitors applications more difficult or troublesome. I've had dealings with both vendors and use both products regularly.

Given the very nature of the delta/snapshot or process monitoring features that dictate the contents of a package, it stands to reason that the "repackaging" aspect of Wise and InstallShield (as well as Prism, ZenWorks, WinInstall, etc.) are fairly equal in what they would generate for a package. While exclusion lists and other differences could be a factor, I would say that generally speaking it is the additional tools, wizards and processes that these tools deliver that helps them to stand apart.

I am talking your question of repackaging an MSI to mean you want to repackage a legacy setup into an MSI package. If you are referring to actually repackaging a setup that is already in MSI format, then I agree completely with cdupuis - don't do it!

Jim,

I agree that InstallShield is not improving their relations with the "administrator community" with InstallShield Script. However from a repackaging standpoint, this should not come into play.

The problem is that lots of developers have been building experience using InstallShield Script for a very long time. When it is used as in the development of a custom action for a MSI package, we end up with the bootstrap (setup.exe) requirement that first ensures the required version of InstallShield Script is available on the system. From a deployment standpoint this is very frustrating to say the least.

The way I see it, these software vendors could very easily stick with InstallShield and not make use of InstallShield Script, but it is available to them as an option- so those that know it tend to stick with it.

As for custom actions, VBS will do the job with either Wise or InstallShield. From a proprietary scripting standpoint- Wise Script is much more "deployment friendly" because it does not have any external dependencies.

Thank you all for the informative feedback, this provides the background information that I needed.

On the same topic, I have been informed that using Installshield (versus Wise) will reduce the effort (time) to develop MSIs. Case in point, on previous projects (1000+ apps) we have found that "on average" it takes 5 days to create, test and QA a repackaged MSI or create, test, QA a MST. I have been told that this effort would be significantly reduced to 1 day, if Installshield Admin Studio is the primary development tool used for packaging / repackaging.

Having had little experience working with Installshield on previous projects, I'm not in a position to either support or contest this statement.

Any clarification would be appreciated!

Bob I agree with you that if vendors didnt include the IS script engine that we would all be better off and I dont hate IS as such...I just dont like the deviation its taking and the amount of people that are getting sucked into it.

I saw recently a case where the IS script engine got corrupted by a demo version installing over the top and killing a couple of IS dll files.
The machine was unable to remove any of the IS applications because of it and required a rebuild.

Now at home I can rebuild my network with ghost images in about 45 minutes. I would hate to tell the board of the bank "oops" we gotta rebuild 2000 workstations because of an error with the IS Script engine.

You see my point?

As for VB scripting.....well we all love to use it......but I'll just say one thing.

Error Checking on VB Script within msi files?

Lets hope Windows Installer 3.0 can add some value functions to help us.

Cannear.....I'm sorry but I dont believe that statement is true.

Building scalable and precision installations takes time no matter what packaging app you use because every environment is different and circumstance always rules in the case of apps installing, working correctly, removing and repairing.

MS in the past used Orca to package their apps.

Sorry I went off topic there....oh well.

Cannear....I suggest to you that you approach a few of the vendors and get some eval copies and try them out. You may find that you "take to" one in particular and are more at ease with the look at feel of it. I believe this will also be a deciding factor in your choice.

If it clicks with you then you have a head start it using it to its fullest extent in the quickest possible time.

Most of the successes you have with either package will end up coming from sheer determination and also the help of forums like this anyway. At least if you feel comfortable with the packaging app you will be starting off in the right way.

We are using Wise Package Studio and we have several times come across problems trying to create Transforms for applications packaged with InstallShield. These applications come as InstallShield .exe files. When executed they install the InstallShield base files and extract a msi file which is then installed.
If you take that .msi to another PC it will complain that the required version of InstallShield is missing. If you install InstallShield (from IIScript8.msi for instance) then you can install the msi. When we try to make a Transform for the msi with the Wise InstallTailor it get right through the process to the last screen (click finish to save the transform) and then will not complete. This has happened several times on unrelated applications and led to us re-capturing rather than using a transform. Is there any solution to make InstallShield and Wise "play nice"?

You must keep in mind that just because you have InstallShield in your arsenal it does not mean that you will be able to easily repackage every InstallShield MSI. The one thing that does catch my interest is Devstudio 6 has facilities to make pure MSIs out of InstallScript. I have not tested that feature so I do not know if an administrator can just walk in and convert the InstallShield MSI from a vendor into something more useable.

Hello Everybody,
What are the patches or update scripts require for Installshield migration ?
eg:- we are having the Installshield developer 9.0 and we would like to migrate to Developer 11.0. So what are the patches or Scripts needed ,as to work with the my applications without any problem ?
Thanks in advance

ORIGINAL: chrismrose1

We are using Wise Package Studio and we have several times come across problems trying to create Transforms for applications packaged with InstallShield. These applications come as InstallShield .exe files. When executed they install the InstallShield base files and extract a msi file which is then installed.
If you take that .msi to another PC it will complain that the required version of InstallShield is missing. If you install InstallShield (from IIScript8.msi for instance) then you can install the msi. When we try to make a Transform for the msi with the Wise InstallTailor it get right through the process to the last screen (click finish to save the transform) and then will not complete. This has happened several times on unrelated applications and led to us re-capturing rather than using a transform. Is there any solution to make InstallShield and Wise "play nice"?


I have done lots of MST's for different ISScript versions. In this case you do not need to use InstallTailor. You just make an mst using Windows Installer Editor and add the needed properties: ALLUSERS - 1, LIMITUI - 1, ROOTDRIVE - C:\, REBOOT - ReallySupress and that's it.
It works perfectly.

I have been told that this effort would be significantly reduced to 1 day, if Installshield Admin Studio is the primary development tool used for packaging / repackaging.

I think an 8 hour SLA for a quality package is too short. It doesn't matter what tool you are using. Some packages take 10 minutes to create, some, over a week. You need to allow yourself some breathing room for those applications that just don't want to work right. If you establish an 8 hour SLA you are only going to wind up with trouble down the road from departments breathing down your neck wondering why their package wasn't ready 2 days ago. It's better to establish a longer SLA and consistently beat it.

Also, I think it is important to differentiate between Installshield pure .MSIs and Installshield InstallScript driven MSIs. I have made plenty of .MSTs for Installshield .MSIs using Wise Package Studio. That being said I've come across a very few Installshield .MSIs that fail with a wise .MST and the only way I have been able to get them to deploy correctly is to create the .MST in AdminStudio.

I'm not going to tell you what product is better because generally we are most comfortable with the product we have been trained on. I do know that your quality of package will directly depend on the level of knowledge of the packager and the willingness to adhere to your companies standards.

I'm not particularily fond of SLA's myself! SLA's are often driven by the business. They ultimately pay for your services, and often expect certain commitments, like time to complete a package. The million dollar question, and one I still pose to significant talent participating on this form - What should this SLA look like? Informing the businesses that on average it takes 40 hours, although a number of factors during the package development efforts could extend this estimate.

The unfortunate thing about SLA's is that they are the baseline used for measuring performance, which is monitored and subsequently reported in a consolidated IT SLA Scorecard. Breaches of the baseline SLA are normally reported to the business units that originally agreed (signed-on) to the initial SLA.

Now the challenge is to define an SLA that is realistic, and in the end, the business is willing to buy into the timeframes you provided.

Regards,
CanNear

SLA's are too often used as clubs because people want finite rules in which everything will fall into. A SLA should be explicit with things such as response times to have things looked at because those are manageable items. Making an explicit SLA for packaging is just a plain bad SLA.

You have to remember all the dependencies involved for packaging. The packager can be available but what about the server team to deal with the license server / database, the application support specialist's availability (if there is one) and let's not forget about the vendor response time / support offerings. With all these handoffs and extra relationships that are outside of the packager's control would you think that it would be smart to write an explicit SLA?

A SLA for packaging should be for what tends to happen 90% of the time. It should be more of a goal than something explicit with finincal implecations if the SLA is not met. I think why businesses want SLAs for packaging is because they want to be able to form timelines around the product delivery. The issue with that is that packaging and delivery are too often and afterthought in the application lifecycle.

In my line of work I see deployments rushed because the app development / architecture portion of the cycle took to long and so the packagers are given a day or maybe two to make the package, have it tested and get it to production. (I am feeling warm and fuzzy already) The packaging phase should be dealt with the same care that the actual application development takes with quality being the priority. Cleaning up a botched deployment can be costly. I blew almost half a month making an uninstall for a badly packaged engineering app. Half a month of my time isn't peanuts and not to mention that I can't "pump" out more apps if I am blowing half a month on an uninstall.

In the end I think a site should plan for 8 hours from the packager to make the MSI on average. There should be no SLA in terms of we'll have the app ready in 4 days because you can't count on app support, testers, vendors or internal IT to be available when you need them to do their part. But we all know how it is the packagers issue that the delivery did not occur on time and nobody had anything to do with the missed timeline.

ORIGINAL: kkaminsk

SLA's are too often used as clubs because people want finite rules in which everything will fall into. A SLA should be explicit with things such as response times to have things looked at because those are manageable items. Making an explicit SLA for packaging is just a plain bad SLA.

You have to remember all the dependencies involved for packaging. The packager can be available but what about the server team to deal with the license server / database, the application support specialist's availability (if there is one) and let's not forget about the vendor response time / support offerings. With all these handoffs and extra relationships that are outside of the packager's control would you think that it would be smart to write an explicit SLA?

A SLA for packaging should be for what tends to happen 90% of the time. It should be more of a goal than something explicit with finincal implecations if the SLA is not met. I think why businesses want SLAs for packaging is because they want to be able to form timelines around the product delivery. The issue with that is that packaging and delivery are too often and afterthought in the application lifecycle.

In my line of work I see deployments rushed because the app development / architecture portion of the cycle took to long and so the packagers are given a day or maybe two to make the package, have it tested and get it to production. (I am feeling warm and fuzzy already) The packaging phase should be dealt with the same care that the actual application development takes with quality being the priority. Cleaning up a botched deployment can be costly. I blew almost half a month making an uninstall for a badly packaged engineering app. Half a month of my time isn't peanuts and not to mention that I can't "pump" out more apps if I am blowing half a month on an uninstall.

In the end I think a site should plan for 8 hours from the packager to make the MSI on average. There should be no SLA in terms of we'll have the app ready in 4 days because you can't count on app support, testers, vendors or internal IT to be available when you need them to do their part. But we all know how it is the packagers issue that the delivery did not occur on time and nobody had anything to do with the missed timeline.


I had to take a step and think about the excellent points you have raised. Rather than monopolize this forum with SLA stuff, I would like to ask another question, something that was triggered by one of your responses.

Uninstalls - Good or Bad? I understand the Application Lifecycle, or I thought I did. Should uninstalls be created for all packages, assuming that they will be distributed through some automated software delivery mechanism?

Regards,
CanNear

This is very good information! Thank you all for the feedback.....

I have had the pleasure of working in a number of companies, some who, in my humble opinion, could have approached their Application Lifecycle a bit differently. One thing I have to come to realize, whether the team uses Wise or Installshield, it often comes down to the local skill sets, and the packaging tool they are accustomed to working with. $$$$ is also another factor in the final decision. I see the value of having both products available, although finding skilled packagers with working knowledge of both products could be a challenge.

Regards,
CanNear

Uninstalls should be a requirement unless re-imaging the desktop for any reason is ok. I know of very few companies that treat their desktop like a true commodity and even then most apps do not allow you to back up the configuration of the application that is often an issue when treating the desktop as a commodity. I have run into this issue with Softgrid because Softgrid treats applications like commodities but application configuration data sometimes becomes valuable especially with engineering applications. Some apps may never be uninstalled but in most cases the day will come when somebody wants to uninstall the application.

For example the uninstall will likely be a requirement for most upgrades and in support situations desktop support will want to reinstall the product completely. If your desktop were a true commodity many shops would still try reinstalling the application before imaging the entire desktop. My personal opinion is that you would be hard pressed to find an environment where uninstalls are not a requirement.

In my line of work I see deployments rushed because the app development / architecture portion of the cycle took to long and so the packagers are given a day or maybe two to make the package, have it tested and get it to production. (I am feeling warm and fuzzy already) The packaging phase should be dealt with the same care that the actual application development takes with quality being the priority. Cleaning up a botched deployment can be costly. I blew almost half a month making an uninstall for a badly packaged engineering app. Half a month of my time isn't peanuts and not to mention that I can't "pump" out more apps if I am blowing half a month on an uninstall.

In the end I think a site should plan for 8 hours from the packager to make the MSI on average. There should be no SLA in terms of we'll have the app ready in 4 days because you can't count on app support, testers, vendors or internal IT to be available when you need them to do their part. But we all know how it is the packagers issue that the delivery did not occur on time and nobody had anything to do with the missed timeline.

Do you and I work for the same company? No wait, you're from Canada --can't be. Reading this post, I felt an almost psychic connection, as I find myself making the exact same observations almost every day. My group lead has a pet saying that perfectly encapsulates this dilemma:

"Failure to plan on your part does NOT constitute an emergency on MY part."

I'd like to see this stamped in bold red letters across the top of every packaging submission form. Won't happen, of course, but it's fun to fantasize. [;)]

This an old topic but here's my 2 cents...

Worked in the industry for 6 years mainly doing Citrix and packaging is just part of my efforts. I've evaluated several products and ended up with Wise, it was the most flexible from an admin perspective.

What I discovered is that most apps, I have to figure out if they are true MSIs or Installshield MSI. My boss thought MSI is a Microsoft standard and took me awhile to prove to him that Installshield makes their own MSI and they are not doing the community a favor by creating their own flavor.

I could care less about Installshield script or who compiles faster, I only care about simplicity and ease of use. Installshield fails at that.

Not to mention, many setups using Installshield setup.exe tend to fail with silent installs on Citrix. Blame on Citrix's Installation Manager for not able to push Installshield MSI but works fine with generic MSI.

A simple wrapper calling a IS setup.exe usually fails in Citrix.

The community need to work on standards and not compete by proprietary features.

<RANT>
I'm getting really sick of hearing this phoney argument from people. Let me set the record straight for all you people that use Wise but think they're Installshield experts:

Installshield will make two kinds of MSI's:
1) A standard MSI
2) A standard MSI with Installscript code inside

You as a packager can choose which you want to make when you're repackaging or coding an MSI from scratch.

Vendors can also choose which kind they want to make.

Choice #2 is the kind we all hate as deployment people, but they exist for a reason. Installscript pre-dates MSI. Installshield invented this scripting language to get applications to desktops before MSI existed. It was excellent at what it did and most vendors adopted it and trained their people in it.

Once MSI came out, vendors had a bunch of people trained in Installscript so what do you think they're going to do? Spend a bunch of money switching over, or continuing on with what they know?

You can't blame Installshield for this. In fact they've done a good job of nudging vendors over to the MSI format.

Both Installshield AND Wise add custom tables to an MSI created with their product. This is so they can add user-friendly features. IS tables don't like Wise and Wise tables don't like IS. It's an issue no matter what product you pick.

Both products have their problems:
Wise is expensive and harder to learn
IS is buggy and bloated

Overall, it comes down to personal preference, but please stop quoting this crap about how Installshield can't make "real" MSI's.
</RANT>

hehe what can I say,

there are linux and windows people fighting for each platform... then there are wise and installshield ;)

hi,

can u send me the common exclusion list of files and registries that we are using in the wise studio 5.6.
if possible send me urgent.

thanks & regards

Abul Khair

Hi All,

I need a help in finding the Exclusion list of common files and registries during the repackaging of application .So if anyone knows please send me those exclusion list.
its urgent for me .


thanks

Abul

I generally always try to use the vendor's installer if it is MSI based, WISE or Installshield. Both of them allow you to send MSI switches to the MSI and therefore in most cases it can be deployed in it's native format. If it is a legacy setup (non-MSI) I almost always repackage to MSI.

ORIGINAL: jbrydell

Windows Installer was meant to be... in a way, open source (Text in a DB, a standard script, and sourcefiles). When InstallShield added their propietary script in installations it was a step backwards in the technology... especially if the script does nothing but launch the MSI, why the heck have it there.

It not there in a Basic MSI, as mentioned many times before..

The previous statement that InstallShield can make regular MSI's is true, except in some versions of the Install Shield tools. I know that in the light version for developers, Install Shield Express I believe it was called.... did not have this option, and automatically but the darn IScript down.
When InstallShield hides the dialogs into an EXE in some versions... what the heck is that for. Someone want to defend InstallShield on that one ... waiting ....

None of the available installshield products do the above, so the points you are making are irrelevant to this topic or to people evaluating these products.. also I think in the older version you could use setup=no to build just a MSI.

To any person out there getting ready to buy... do a complete look at the tools. Quite honestly it was apparent in my career that InstallShield was loosing their market share, and tried to be sneaky to hold on... not exactly professional and then in and of itself was enough for me to make my choice. And oh yeah, you want a real joke... look at the history behind something called NetInstall.

I see no mention of when InstallShield sued Wise for stealing proprietary information in 2003 and 2006 thats sneaky and shady, also Altiris paid $43 million in cash and stock for Wise, Macrovision paid $76 million in cash for InstallShield, Installshield is used by most Global Service Providers and nearly all of the top 100 software publishers so I dont think they have a problem with market share..

HOWEVER, there is never been an install from InstallShield that I could not hack or crack one way or another ... it is simply extremely annoying that they built their tool this way forcing people to either jump through all the hoops, or buy their tool to build the unattended installation. Shady!

Its hardly rocket science to get a InstallShield MSI installed.. and why would you need their tools to build something thats already been compiled and how many times do developers leave the project file in? The important point is it is developrs making stupid installation packages, not people repackaging..

Most of your observations are historic and about as relevant as these awards...

2007 Awards
http://redmondmag.com/features/article.asp?editorialsid=706


2006 Awards..

2005


BTW I think wise is a good product but a balance needs to be found in these comparisons..

I couldnt resist this one.

I agree with Jim and Wildhair on this one. Installshield is introducing another level of complexity to something which could likely be done without Installscript maybe not as quickly. But in the end who pays for this.

From the developer perspective its fast and easy from the admin perspective its not. One would assume it depends on which side of this fence you are sitting on and who is paying the bill in the long run.

Cannear as for your comments on cutting down your packaging / QA / testing time from 5 days to 1 day I would disagree with this comment completely.

If either product was capable of doing this Wise would be the closest as it support the virtual packaging theme. However in saying that I don't think either of them are capable of reducing such timelines.

If you want to reduce your time to build, spend it on training and make sure the trainer knows what they are talking about.

Having a solid understanding of Windows Installer fundamentals will be the quickest way to reduce packaging times, no tool can compete with understanding of the underlying technology.

Finding someone that has a clear concise understanding of the installation sequences / self healing and such and more importantly can relay this information well and accurately will hands down be better than spending money on tool selection.

If you understand the technology the tool is less important.

I've posted this many times, but for those that aren't educated on Installshield, I'll repeat it again.

When using Installshield you can make four types of installers:

1) pure MSI
2) MSI with Installscript dialogs
3) MSI with Installscript custom actions
4) Installscript setups

1) does not require the installscript engine
2) only requires the installscript engine if running the dialogs (silently you're fine)
3 and 4) requires the installscript engine

The question that keeps coming up is "Why are 2,3, and 4 options.. is it because Installshield is evil or stupid?"

The answer is "no". Those options are there for LEGACY SUPPORT. Before MSI existed, almost every vendor created setups with installscript. Vendors invested heavily in installscript and wanted to continue to use that technology after MSI came out. Installshield allowed vendors to continue to use installscript if they wished, but pushed them heavily in the direction of the MSI-creating tool.

Some companies still use installscript. That's hardly Installshield's fault. Really, it's Microsoft's fault for not inventing MSI with their first operating system. So please stop whining about Installshield.. please.. it's tiresome.

Its hardly rocket science to get a InstallShield MSI installed.. and why would you need their tools to build something thats already been compiled and how many times do developers leave the project file in? The important point is it is developrs making stupid installation packages, not people repackaging..

Yes, who is doing the packaging does matter as much as what tool they're using, that much is true. However, the former statement completely misses the point. A modern-day MSI packaging tool BY DEFAULT SHOULD ALLOW YOU TO EASILY CREATE A PURE MSI, without having to: a) purchase a 'super-premium' version, b) go in and change the default option from 'proprietary' to 'real MSI', or c) includes some crappy scripting engine that's not even backward compatible with prior versions of itself.

What if your company requires certain modifications that must be added by transform to every vendor MSI? Such as: custom properties, custom actions, permissions scripts (because of locked down workstations), the need to suppress any InstallShield reboot triggers, or need shortcuts moved to a special location, etc. What if they require fully automated and silent MSI deployment with no user-dialogs? Anyone, anyone...? Mine does, and I'm sure there are many other large companies out there that do as well. If you need NOTHING CHANGED, REMOVED, OR ADDED, then, sure, an InstallShield-wrapped MSI/Exe hybrid is just fine.

I freely admit that Altiris/Wise Package Studio 7.x is buggy --far too buggy for such an advanced version, quite frankly-- and bloated, though no more bloated than the current IS Admin Studio. Perfection it's not. But I have always been able to build more-or-less "pure" MSIs that can be easily modified and/or transformed with any other MSI tool (Orca, WinInstall, etc.) and will deliver silently with any vendor's software delivery tool without bombing out due to some proprietary 'feature' (SMS, Altiris, Radia, Tivoli, etc.). This alone earns the product some kudos in my book.

Yes I agree, some times u have the install shield extracted Setup are almost impossible to repackaged using Wise.[:@]

you do know this is a 2 year old thread....right?? lol :).

Yes Jacurri,

I do know the tread is two years old. However who knows what info is helpful to the users.... [:)][:D]....

Any ways why did u look into 2 years old thread... lot spare time I guess lol..

ORIGINAL: yshariff

Any ways why did u look into 2 years old thread... lot spare time I guess lol..



Spare time aside, I, like many here, read just about every new post in an effort to help answer questions people may have and every so often learn something new in the process.

Great, Can you help in understanding Wise Scripts. I mean how can I start learning to write wise scripts.

how can I start learning to write wise scripts.I wouldn't bother. Wise is dead in the water. Learn VBScript (for packaging purposes) and PowerShell (for future employment purposes).

I personally think Wise could create a package faster than IS purely for these reasons.

1) the component structure is customisable (based on the skill of the user)
2) the wise macro editor allows code to be written to automate a large part of the process where as the installshield scripting is designed for use at runtime. A huge huge difference in my opinion when discussing speed of output. All apps generated on my site are automatically QA'd to standard, automatically documented and for the most part automatically configured due to comprehensive macro code. Not to mention automated training course built into the code.
3) conflict manager is better designed for corporate deployment use (i.e. the repackager / admin user deployment).

both have benefits and there is a strong driver to what your project needs to do. Is seems better suited to single application SDLC type work.

Wise is better suited to Corporate enterprise application sociability work with fast turn around and silly SLA's.

There is a new player on the market claiming to be better than both called packaging robot.

Haven't used it seen it in operation, don't really see how it can be faster but I can't judge it for sure until I can get it to use.

Hi Wild Hair,

Good to see some one who is so much experienced on Wise Tool...
I Guess you are the right person who can help me out on how to start learning Wise Scripting and also how to use the Software manager in Wise.

I am using Wise 8.

Interesting debate. We are looking at Wise vs IS right now. it seems to me that Symantic really doesn't care about Wise and it will wither and die. I hope i am wrong, i have used wise for 11 years now and it is near and dear to my wallet.

The interesting feature of their Admin Stuidio is taking things and porting directly into VMWare ThinApp & AppV. ThinApp is the front runner in our eval.

ORIGINAL: jmcfadyen

I personally think Wise could create a package faster than IS purely for these reasons.

1) the component structure is customisable (based on the skill of the user)
component structure is customisable in repackager although its not nearly as granular as Wise


2) the wise macro editor allows code to be written to automate a large part of the process where as the installshield scripting is designed for use at runtime. A huge huge difference in my opinion when discussing speed of output. All apps generated on my site are automatically QA'd to standard, automatically documented and for the most part automatically configured due to comprehensive macro code. Not to mention automated training course built into the code.
You are comparing IS scripting engine to wise macro's which is like comparing vbscript to html, the scripting engine is not used for package automation the ISWiProject Object Automation Interface is.. no one repackaging for enterprise uses isscript.
http://helpnet.acresso.com/robo/projects/installshield15helplib/IHelpAutoISWiProject.htm

The whole process can be automated in adminstudio..


3) conflict manager is better designed for corporate deployment use (i.e. the repackager / admin user deployment).
The conflict management in adminstudio is designed for the enterprise and it highly configurable - I dont understand where you are coming from


Wise is better suited to Corporate enterprise application sociability work with fast turn around and silly SLA's.
I would say they are equally capable for delivering fast turn arounds..

Tone,
You are comparing IS scripting engine to wise macro's which is like comparing vbscript to html, the scripting engine is not used for package automation the ISWiProject Object Automation Interface is.. no one repackaging for enterprise uses isscript.
http://helpnet.acresso.com/robo/projects/installshield15helplib/IHelpAutoISWiProject.htm

The whole process can be automated in adminstudio..


The point I was making here is the two scripting methodologies are completely different and serve completely different purposes. One to aid the build time phase one to aid the install time phase. Two scripting languages with completely different purposes.

[blockquote]
3) conflict manager is better designed for corporate deployment use (i.e. the repackager / admin user deployment).

[/blockquote]
I recently had this same discussion with Installshield themselves. They did a presentation for me and I presented a number of situations that I believed it didn't support. The respones back from IS was that I was in fact correct and IS didn't cater for this situation and each application would need to be managed individually.

My concerns were this.

Imagine you have 10 packages all pushed into CMDB without being managed.

Package A - Component Code A same file same location
Package B - Component Code B same file same location
Package C - Component Code C same file same location

As I understood and how IS confirmed was that it could not tell Package C which application to match against if there were 2 contention applications.

Package C should match to both A and B assuming they were the same. However in a state where for some reason A and B were not in sync then C could not be accurately matched. The respones from IS team was in that case A - B should be managed to get a match then C should be added to match to A and B.

This in my opinion is flawed and you should have an option to match to either A or B as you do in Wise. IS is code driven from the ACE / CARD logic. Wise is optionally code driven or manually assigned.

If you can explain otherwise I am all ears a this is my biggest contention with IS CMDB, Installshield couldn't do this and I am happy to post their responses in here if you dont take my word for it.

The point I was making here is the two scripting methodologies are completely different and serve completely different purposes. One to aid the build time phase one to aid the install time phase. Two scripting languages with completely different purposes.


You compared isscript engine with the wise macro's when the two are not comparble, which is just plain confusing to anyone reading.

The comparison should be against the wise macros and is automation - you stated IS can only do automation at run time.


conflict manager is better designed for corporate deployment use (i.e. the repackager / admin user deployment).
I jumped in a bit to quick here reading what you wrote as installshield isnt designed for corporate/admin deployments.

for what you need installshield isnt up to speed - for me its fine as I expect all engineers to have a syncronised ISM and MSI and this is manual step.

Can we close this ancient thread? Wise is dead, this debate is over.

Wise hasn't been "updated" for a long time but it's not dead.
After a chat with Mike (the Wise PM) I got the info that the life-cycle will start spinning once again.

I had that chat too, and I was not so convinced. Did you ask any hard questions about real W7 (the new WI) support?
We're tied by a NDA so we can't really discuss this publicly, but requiring an NDA to discuss future support the competitor has had for some time.. that says enough I think.

TK

I usually talk with Mike by email, just general chatting but was interested in how the dev team was holding up.

I've been under NDA ~4 years now since being part of the Altiris Forum Advisor group which is now replaced by the Symantec Trusted Advisor group at the Symantec Connect community after they took Altiris under their wings ;)

I'm sure we'll see some development taking place, so why not start adding features/enhancements to the wishlist in the http://itninja.com/question/help-publish-appz-via-.cmd6 thread as Rob has already started.

Cheers!

ORIGINAL: AngelD

Wise hasn't been "updated" for a long time but it's not dead.
After a chat with Mike (the Wise PM) I got the info that the life-cycle will start spinning once again.



So 16 months later ....... how's the optimism on that refresh of Wise ?

I'm with a global corporate with many Wise installations and we are very close to going to the competition.

that refresh of WiseAs I believe I said earlier this week in another thread: oink, flap.

Have you trialled v8? If you did and didn't come to the conclusion that it's really v7 SP4 and that by laying out thousands of [insert your currency here] you will be royally taken for a ride, then by all means upgrade.

The only way the Wise family will stand any chance of keeping up is if it escapes from Symantec who, let's be honest, acquired Altiris purely for the deployment technology. My guess is that that will happen before the end of 2011.

i gave up both products I find notepad and WiX is the best MSI editor these days.

that's interesting. Wix is free isn't it?
only problem is it prolly can't do setup captures etc....or can it?
thanks

No need for snapshots. use procmon to see which files/registry are needed ;)

Well everyone here knows my quote but I'm always happy to restate it.

Wise makes MSI's
Installshield makes Installshield MSI's

And there is a difference!

Wise does not put down its own engine to enhance The Windows Installer service but Installshield does and there in lies the difference between them.

There is no conspiracy at all.....Just a deviation from a standard.
MSI is a Standard and is fully ratified as such. MS patented it and fully supports it as a
STANDARD.

Installshield is bastardising a standard simple as that.

I agree fully with cdupuis in that we shouldnt repackage vendor msi's but this was the norm 3 years ago. Nowdays some vendors hire any cowboy to create msi installs that dont come close to adhereing to the Windows installer credo or standard.

For a start very very few vendors silo there system dll's or use .local files to stop invasion of the System32 folder. There is no need to include System32 based files to that folder. They can be siloed to the applications folder in all 32bit cases. But vendors dont even do it. So we are up against it to start with.

If you decide to use Merge Modules then you have to constantly upgrade them every time there is a code change or service pack. No one has the time to keep track of that info. So the dll counter is really useless in practical terms.

I work for a very large bank (30,000 users) and to actually be allowed to install a file to the System32 folder requires me to prove to a techo Commitee that the app wont work without it. So I have to repackage most if not nearly all vendor msi installations.

With my current hate app...Acrobat Elements, the vendor, Adobe has included a custom action to actually stop deployment of their app via Group Policy in AD!!!!

Now you can't honestly tell me that Adobe was advised to do that by the packagers who did the app for them. It's beyone reason to believe that is possible.

I have been packaging a long time now.......5 years and I see alot of really bad things going on in the vendor based installations and luckily a huge amount of really good things going on in the "repackaging" scene.

Hopefully knowledge transfer points like this site will continue to provide sound and scalable information for the future because we surely need it.

Rant over :)

I know this debate goes on and on about InstallShield versus Wise ... but I felt the need to add my two cents.

In my career I have been exclusively packaging software since 1998, and scripting installs before that. Additionally I jumped into MSI's when they first hit the market... originally with ORCA. I've used Lanovations (AKA Prism/Picture Taker), Wise, Install Shield, WinInstall, Walls, and a few others not worth mentioning. Many times I have been asked at different companies to complete a show-down of tools. Every time Wise has come out ahead, and on occasion Install Shield was a close second. So if someone is really looking for a tool to get the job done, I would suggest one of those.

I have to state the facts here as I have come across them in my career though, and why I think InstallShield gets trashed on so often, and why I have ultimately usually chosen to use Wise myself... defend the tool all you want, this is simply my opinion.

Windows Installer was meant to be... in a way, open source (Text in a DB, a standard script, and sourcefiles). When InstallShield added their propietary script in installations it was a step backwards in the technology... especially if the script does nothing but launch the MSI, why the heck have it there.
IScript version 6 - 8.5 had incompatibility issues with each other, and the last version installed wins!! Not exactly professional coding there people, I thought we learned our lessons back in the 95 NT4.0 dll hell days. Maybe a new CLSID might have been a good idea.
I have actually caught InstallShield installations specifically deleting the ~wrepack Wise folder from the %TEMP% folder location, while leaving other folders there. This breaks the Wise Setup Capture. I have seen this twice, and gave the info to Wise to figure what to do with it. (Simply copy the folder, do the install, and place the folder back to get around this annoying little item)
The previous statement that InstallShield can make regular MSI's is true, except in some versions of the Install Shield tools. I know that in the light version for developers, Install Shield Express I believe it was called.... did not have this option, and automatically but the darn IScript down.
When InstallShield hides the dialogs into an EXE in some versions... what the heck is that for. Someone want to defend InstallShield on that one ... waiting ....
To any person out there getting ready to buy... do a complete look at the tools. Quite honestly it was apparent in my career that InstallShield was loosing their market share, and tried to be sneaky to hold on... not exactly professional and then in and of itself was enough for me to make my choice. And oh yeah, you want a real joke... look at the history behind something called NetInstall.

To be the devils advocate here.... Later versions of the InstallShield tools have certainly grown up, and I keep a copy of AdminStudio around just to do the odd IScript front ended installs I run into. HOWEVER, there is never been an install from InstallShield that I could not hack or crack one way or another ... it is simply extremely annoying that they built their tool this way forcing people to either jump through all the hoops, or buy their tool to build the unattended installation. Shady!