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

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.

Answers

0
Lots of topics on this.. use search.
Answered 02/20/2007 by: turbokitty
Sixth Degree Black Belt

Please log in to comment
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.
Answered 02/20/2007 by: joedown
Second Degree Brown Belt

Please log in to comment
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.
Answered 02/20/2007 by: turbokitty
Sixth Degree Black Belt

Please log in to comment
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!
Answered 02/20/2007 by: jib
Purple Belt

Please log in to comment
0
Got it. Thank you all for the input and hints! [:)]
Answered 02/22/2007 by: danr29
Purple Belt

Please log in to comment
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
Answered 02/28/2007 by: jamsek19
Orange Senior Belt

Please log in to comment
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
Answered 03/02/2007 by: nheim
Tenth Degree Black Belt

Please log in to comment
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
Answered 03/06/2007 by: jamsek19
Orange Senior Belt

Please log in to comment
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
Answered 03/06/2007 by: nheim
Tenth Degree Black Belt

Please log in to comment
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
Answered 03/09/2007 by: jmcfadyen
Fifth Degree Black Belt

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