/build/static/layout/Breadcrumb_cap_w.png

Resources in Packages - Where do they go?

I have a package which distributes a 16-bit appllication. At the end of the install, I need it to run the following commandline:

wkix32.exe configapp.kix


configapp.kix does some varioous configuring of the application. It also needs to call a command-line utility (say, util.exe)

So I need to include the following files:

wkix32.exe
configapp.kix
util.exe

When I add these files to "Resources" in the package, where do they get extracted to on the destination computer? Is there a better way to package these three files?

0 Comments   [ + ] Show comments

Answers (9)

Posted by: turbokitty 18 years ago
6th Degree Black Belt
0
What tool are you using? Wise? Installshield?

Is this a vendor MSI or one you created?
Posted by: sixdoubleo 18 years ago
Senior Yellow Belt
0
Oops...sorry. Wise Package Studio 5.52 Professional

This is an MSI that I created by taking a snapshot of the 16-Bit application. However, I need to have it run this script after installing.

Also:

In the MSI Script tab, under Execute Immediate, I have chosen "Execute Program from Destination". However, I need to know where my wkix32, configapp.kix, and support file util.exe will be extracted to so I can build the command line.

Another Edit:

This all works fine if I locate wkix32.exe, coinfigapp.kix, and util.exe on a network share and have the package reference the files that way. The MSI launches the kix script just fine. However, I want to include everything in the package.
Posted by: turbokitty 18 years ago
6th Degree Black Belt
0
Hmm.. this is pretty straight forward. The resources get delivered to wherever you specify when you add them to your WSI.
Open your WSI project file and open the Installation Expert view. Then go to the Files section, and add you files to wherever... I recommend the INSTALLDIR.
Then open the MSI Script view. Choose "Execute Program from Installation".
Details tab: Give it a name, browse to the folder in your installation where you added the file (wkix32.exe), add your arguments (coinfigapp.kix).
Location tab: Choose your sequence (probably Administrative Execute Immediate/Deferred). Move it down to wherever in the sequence you want it (must be after Install Files in this case obviously).
Properties tab: set Inscript Options to Deferred Execution, Process is Synchronous.

Done. Unless I forgot something. You really need the courseware if you want to learn this stuff as the Wise Help is crap.
Posted by: sixdoubleo 18 years ago
Senior Yellow Belt
0
ORIGINAL: turbokitty

Open your WSI project file and open the Installation Expert view. Then go to the Files section, and add you files to wherever... I recommend the INSTALLDIR.



Thanks for the reply turbokitty. However, I was putting these in the "Resources" area rather than the "Files" area. Should I use the Files area instead? See, my understanding was that since these files (wkix.exe, configapp.kix, and util.exe) are not part of the installed application itself, but rather are temporary support files for the install, then they should go under "Resources".

I read this article by Bob Kelly..

http://www.wise.com/Library/CustomActionsWithKiXtart.pdf

which talks about using a kix script from an MSI, and he used the Resources area for his EXE.

Again, thanks for the response... So I guess now the question is whether I should put these in Files or Resources? What is the general rule of thumb here?
Posted by: DavidLock 18 years ago
Senior Yellow Belt
0
If you put them in resources then are streamed in to the binary table. In Wise just create a custom action of type "Execute program from installation" and it will put these in the binary table for you. At install time it will extract and run whatever command line you put. You don't need to know where it is extracted. Try it and you will see that you can add a command line. Then just schedule the action wherever you want.

So you never need to add things to the Resources table yourself or know about the temp directory.

Another thing to do is check out exactly what changes this script is making. if it is doing dynamic changes then you will have to stick with a custom action however if it just making a static change, like changing a registry key and this is always the same for all machine then you could just put that change in the MSI itself.
Posted by: sixdoubleo 18 years ago
Senior Yellow Belt
0
This script is making dynamic changes to file permissions that I have been unable to duplicate in the MSI.

I understand that the MSI "knows" where the resources are. But if my script is calling util.exe (which is in the resources) how will my script know where to find this utility?
Posted by: turbokitty 18 years ago
6th Degree Black Belt
0
You can stream the Kix executable but you can't stream util.exe.. as far as I know. You'll have to stick that in INSTALLDIR, no??
Posted by: sixdoubleo 18 years ago
Senior Yellow Belt
0
ORIGINAL: turbokitty

You can stream the Kix executable but you can't stream util.exe.. as far as I know. You'll have to stick that in INSTALLDIR, no??



That's what I was wondering. In fact I bet I can't stream the kix script itself. It seems the only thing I can stream is the kix32.exe itself. The script and any support files must go somewhere else.

But I don't want the script or the support files laying around after the install, so how should I approach this?

Should I dump the support files into INSTALLDIR and then delete them when I'm done?

Or can I direct the MSI to stick the support files in %TEMP%?
Posted by: turbokitty 18 years ago
6th Degree Black Belt
0
Either/or.

Be sure to make your custom action only run on install. The details are in that pdf you mentioned earlier.
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