Separate Directories vs. MSI/MST? (Newbie Ques)
Please forgive my ignorance, but I am new to packaging and just trying to get up to speed...
It is my understanding that you have a vendor MSI, and you create MST's for any type of changes or alterations you would like to make to the install process. This process results in two files; application.msi & application.mst -- this has been my practice/procedure so far (but only for two packages) with AdminStudio 7.5
I came across some packages that a previous employee was working on, but they seem to be in a different format than the 'regular' two files (MSI & MST). They have one small MSI (580kb) and several folders with subfolders and files;
\app.msi
\All Users\Start Menu\Programs\App Shortcut
\System32\applicationdll1.dll
\System32\applicationdll2.dll
\System32\applicationdll3.dll
\Windows\application.ini
There are many files in the System32 folder (approximately 122), so I didn't list them all, but they are DLL's, DAT's, etc -- all the typical system files.
It appears to me that the small MSI copies over all the files in the folder structure to the destination machine where the application will be installed.
Can anyone shed some light on how this is achieved with many separate folders/files rather than one self-contained MSI? What is the difference in this format (with separate folders & files) compared to a more compact format of just a MSI and MST? Which is easier to manage/maintain?
Thanks for any clarification you can provide.
It is my understanding that you have a vendor MSI, and you create MST's for any type of changes or alterations you would like to make to the install process. This process results in two files; application.msi & application.mst -- this has been my practice/procedure so far (but only for two packages) with AdminStudio 7.5
I came across some packages that a previous employee was working on, but they seem to be in a different format than the 'regular' two files (MSI & MST). They have one small MSI (580kb) and several folders with subfolders and files;
\app.msi
\All Users\Start Menu\Programs\App Shortcut
\System32\applicationdll1.dll
\System32\applicationdll2.dll
\System32\applicationdll3.dll
\Windows\application.ini
There are many files in the System32 folder (approximately 122), so I didn't list them all, but they are DLL's, DAT's, etc -- all the typical system files.
It appears to me that the small MSI copies over all the files in the folder structure to the destination machine where the application will be installed.
Can anyone shed some light on how this is achieved with many separate folders/files rather than one self-contained MSI? What is the difference in this format (with separate folders & files) compared to a more compact format of just a MSI and MST? Which is easier to manage/maintain?
Thanks for any clarification you can provide.
0 Comments
[ + ] Show comments
Answers (6)
Please log in to answer
Posted by:
AngelD
17 years ago
This MSI uses "uncompressed external files" instead of "internal cab" which is stored as a data stream inside the MSI, you can even have external cab.
There is now right or wrong in the choosing how to store the media files.
If you have internal CABs then it will go faster to deploy over network.
Do you choose to have the files in the same location as the MSI ("uncompressed external files") then you will be able to patch the media so you can deploy the updated package to the clients.
I mostly use "uncompressed external files" which will:
make it easier to update/remove any files I want for the next version (update package)
patch the administrative installation
using script to handle the media whenever I need
If you look in the Media table there is a Cabinet column which defines how the source files are handled.
A blank column means external files, starting with a "#" character means internal CAB(s) and not starting with "#" means external CAB(s).
Using internal CAB(s) will also require more space on the target machine as during execution of the CostInitialize action it will calculate hos much free space is required for the package including files and the internal CAB(s).
So if you have a large package, lets say the files take up 1GB and you use internal CAB the FileCost will be 1GB + the size of the CAB.
Hope this gives you any idea in which way you want to handle your packages.
There is now right or wrong in the choosing how to store the media files.
If you have internal CABs then it will go faster to deploy over network.
Do you choose to have the files in the same location as the MSI ("uncompressed external files") then you will be able to patch the media so you can deploy the updated package to the clients.
I mostly use "uncompressed external files" which will:
make it easier to update/remove any files I want for the next version (update package)
patch the administrative installation
using script to handle the media whenever I need
If you look in the Media table there is a Cabinet column which defines how the source files are handled.
A blank column means external files, starting with a "#" character means internal CAB(s) and not starting with "#" means external CAB(s).
Using internal CAB(s) will also require more space on the target machine as during execution of the CostInitialize action it will calculate hos much free space is required for the package including files and the internal CAB(s).
So if you have a large package, lets say the files take up 1GB and you use internal CAB the FileCost will be 1GB + the size of the CAB.
Hope this gives you any idea in which way you want to handle your packages.
Posted by:
JdotQ
17 years ago
AngelD,
Thank you for the reply. Would the best way to get the uncompressed external files be to perform an administrative install via msiexec /a ?
I believe after reading your explanation I would like to go the route of the uncompressed external files.
You would go about customizing them the same way with a MST?
Thank you for the reply. Would the best way to get the uncompressed external files be to perform an administrative install via msiexec /a ?
I believe after reading your explanation I would like to go the route of the uncompressed external files.
You would go about customizing them the same way with a MST?
Posted by:
JdotQ
17 years ago
Just to expand on this...
I just downloaded Acrobat Reader 8.0, and it came as one file (AdbeRdr80_en_US.exe - 21mb)
I executed this and was able to get the files;
\Abcpy.ini
\AcroRead.msi
\Data1.cab
\Setup.exe
\setup.ini
Inside the .cab file are all the separate files... How do I get the files inside the .cab to 'extract' to the destination folder structure (ex. Program Files, System32, Common, etc) ?
I've created a MST to customize the MSI install, but was interested in trying this out with the separate folder structure.
Hope this makes sense...
Thanks in advance for any help and/or guidance
I just downloaded Acrobat Reader 8.0, and it came as one file (AdbeRdr80_en_US.exe - 21mb)
I executed this and was able to get the files;
\Abcpy.ini
\AcroRead.msi
\Data1.cab
\Setup.exe
\setup.ini
Inside the .cab file are all the separate files... How do I get the files inside the .cab to 'extract' to the destination folder structure (ex. Program Files, System32, Common, etc) ?
I've created a MST to customize the MSI install, but was interested in trying this out with the separate folder structure.
Hope this makes sense...
Thanks in advance for any help and/or guidance
Posted by:
nheim
17 years ago
Hi JdotQ,
your on the right track. To get all the files, you can do an administrative install with msiexec /a AcroRead.msi. Then you get a dialog to choose the destination directory. This works with Acrobat Reader and quite lot of MSI's, but you can't relay on it, because the MSI developer has to author the apropriate tables.
Regards, Nick
your on the right track. To get all the files, you can do an administrative install with msiexec /a AcroRead.msi. Then you get a dialog to choose the destination directory. This works with Acrobat Reader and quite lot of MSI's, but you can't relay on it, because the MSI developer has to author the apropriate tables.
Regards, Nick
Posted by:
JdotQ
17 years ago
nheim,
Thank you for the reply. That was along the same track I was thinking. And you are correct, not all MSI's will extract to the nice subfolder structure, as I've come across this already. But this Adobe Reader did extract nicely, in subfolder fashion.
Aside from just extracting the cabs/creating a folder structure, does performing an administrative install have any benefit than just 'hosting' files on a network share to be deployed?
Thanks again.
Thank you for the reply. That was along the same track I was thinking. And you are correct, not all MSI's will extract to the nice subfolder structure, as I've come across this already. But this Adobe Reader did extract nicely, in subfolder fashion.
Aside from just extracting the cabs/creating a folder structure, does performing an administrative install have any benefit than just 'hosting' files on a network share to be deployed?
Thanks again.
Posted by:
nheim
17 years ago
Hi JdotQ,
you can patch an admin installation. That's the main advantage, i see.
Regards, Nick
you can patch an admin installation. That's the main advantage, i see.
Regards, Nick
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.