/build/static/layout/Breadcrumb_cap_w.png

Installshield Script Engine

I know how to remove the dependancy of setup.exe from an .msi created in installshield, but is there a way to remove the .msi's dependancy on the IS Script Engine? I'm thinking there's not, but if anyone has a different answer please let me know. Thanks.

-Dan

0 Comments   [ + ] Show comments

Answers (10)

Posted by: turbokitty 17 years ago
6th Degree Black Belt
0
Lots of topics on this.. use search.
Posted by: joedown 17 years ago
Third Degree Brown Belt
0
I don't believe this is possible. Just install the right isscriptX.msi before the main application. I don't know why they do it like this. I really hate scripted msi installations. The MSI is the only thing that MS ever did half right and another company comes along and whores it.
Posted by: turbokitty 17 years ago
6th Degree Black Belt
0
ISScript came first actually and don't get me started.

Use "Search", what you're trying to do CAN be done and AngelD has posted a lot of detail on this topic.
Posted by: jib 17 years ago
Purple Belt
0
Common "best practice" (according to myself, and some others, mind you .. ) is to use an isscript.msm of the correct version and put that in a mst which you deploy togheter with the vendor msi.

Problem is sometimes its hard, bar on impossible, to get the isscript.msm you need. Again, more on this on these very forums :) Do some reading!
Posted by: danr29 17 years ago
Purple Belt
0
Got it. Thank you all for the input and hints! [:)]
Posted by: jamsek19 17 years ago
Orange Senior Belt
0
Hello.
I want to mentioned besides all those answers:
I've created a .msi package which do not uses any IS feature: Custom actions a pure in VBS (included as .vbs file) and .ism file is BasicMSI project type.
Package build is configured to not create setup.exe file and media format is Network image compressed. Cab files are included into .msi package.

Therefore I do not need to include and additional IS merge module or installing any additional IS package.

Best regards
Andreo
Posted by: nheim 17 years ago
10th Degree Black Belt
0
Hi Andreo,
and what are you doing with those dozens of vendor-packages built with the need of a IS script engine?
All most all the talk about this issue is targeted at such situations.
With those, you don't have the possibility to make your suggested decision. We all just have to live with it and make it as smooth as possible.
So, this is not a IS script yes/no question. It's a 'how-to' or best practice thing.
Regards, Nick
Posted by: jamsek19 17 years ago
Orange Senior Belt
0
I meant from package creator prospect, not from user prospect.
So, my opinion is: if package needs IS run time libraries, programmer or package creator must creates a package so, that users (those who installs the application) don't taking care of IS run time just run some .exe or .msi file. That's it.

Finally,
Nheim, if you are a package creator than you can follow my advices. If you are a user who needs application, than you can complain at package author that package is not well done.

Best regards
Andreo
Posted by: nheim 17 years ago
10th Degree Black Belt
0
Hi Andreo,
you are right of course! And more and more vendors/package creators are hearing and reading our (the users) complains about this. But I'm afraid, that it is going take quite a while, till this issue will be history. :-)
Regards, Nick
Posted by: jmcfadyen 17 years ago
5th Degree Black Belt
0
you cant remove the dependancy but it is certainly a good idea to extract the ISScript and its dependant MSI.

leaving it in MSI format causes issues with sourcelist pointers.

when installing from an exe it extracts everything to your current temp folders then installs from there.

this of course leads to another issue if you ever cleanup the source list (some apps do this themselves DUH!)

as such your MSI no longer has its original source installation media breaking self healing etc.

I would recommend removing both the ISScript and its MSI.

Then you also could run into issues based on the current deployment tool you use.

ISScript creates DCOM objects on its target workstation them promptly permissions them so only local users have access to the DCOM objects which is pretty defeatist in my opinion.

As such some remote deployment tools such as GPO etc can fail acccessing the DCOM with a message saying its not installed when in reality its simply permissioned incorrectly.

In this case reset the perms using APPID registry keys and your good to go.

John
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ