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
-Dan
0 Comments
[ + ] Show comments
Answers (10)
Please log in to answer
Posted by:
joedown
17 years ago
Posted by:
turbokitty
17 years ago
Posted by:
jib
17 years ago
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!
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:
jamsek19
17 years ago
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
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
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
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
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
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
Posted by:
jmcfadyen
17 years ago
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
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.
so that the conversation will remain readable.