/build/static/layout/Breadcrumb_cap_w.png

RePackage vs Silent Switches !!!

I got a basic doubt related to repackaging, if I got an executable for the packaging first I will check whether it is vendor msi or not and if it is vendor msi i will create a transform by using Adminstudio (which ever tool) and ll write a batch script to deploy msi and mst so I am happy in this case...

But If the executable is not a vendor msi I will have tweo options here a) Deploy using silent swtches with the help of scripts b) Repackage the application and create a msi using AdminStudio

here always for these king of apps, in the official websites I get the silent installation info by using silent switches/ using .ini files/ using response files something like that so I am usually following that... So am I following the good practices for enterprise deployment ??? or do I need to repackage it whether in the official website they mentioned silent switches??

How to decide should I repackage or use just silent switches as mentioned in the wesite ???

some examples for it are (Mozilla Firefox, Wireshark, 7zip, MATLAB...)

Thanks...


0 Comments   [ + ] Show comments

Answers (4)

Answer Summary:
Posted by: philologist 11 years ago
Red Belt
4

I personally just use whichever method is simplest.  If the vendor-supplied silent installation method works with the vendor-supplied executable or msi, why spend the time repackaging everything?

Posted by: ontari.ontari 11 years ago
Black Belt
1

Thanks Jagadeish n Philologist for your help, here I would like to make a point why I got this doubt

- If we make a msi the advantage of msi like (self repair, decresed support calls.... etc) we can get right?? is that the reason my company hired me?? to create msi and to reduse their suport cost ???


Comments:
  • Yes.. Correct.. - jagadeish 11 years ago
  • If you find creating the MSI packages actually reduces support time before you need to repackage a newer version, it is worthwhile, but if you spend more time converting EXE packages into MSIs than supporting an EXE that works out of the box, you've lost the battle. ; ) - philologist 11 years ago
  • :)
    l**y packagers are selecting the most easier method which will make their work easier and reduce the packaging time but before that they should think that how their package is going to help their customer and how much they care about providing quality packages to their customer.. - jagadeish 11 years ago
  • It's not about being lazy, it's about being efficient with one's available effort. Redoing work that is already done adequately doesn't provide quality packages and support; it spends time that could have been put toward something that needed more attention. If you have that time to spare, sure. - philologist 11 years ago
  • hmm..How do we apply industry best practices and How do we get advantages of msi when we do silent setup for exe installation - jagadeish 11 years ago
  • In theory, msi packages deliver benefits over the silent exe setup.

    In practice, if it takes more time to repackage and support a silent exe as an msi than to deploy and support the silent exe, what have you gained other than theoretically following best practice?

    If the vendor will support an exe, but not a repackaged msi, should you still convert it? What if company policy is not to deploy software unless it is fully supported?

    Sometimes the advantages are outweighed by the amount of time it takes to produce the advantages, or by secondary requirements. Best practices are guidelines; every environment is different. - philologist 11 years ago
  • I'm not asking you to follow best practices theoretically, What i'm saying is implement it in your package and gain the advantages..

    Are we going to vendor for every exe installation and asking them that will they support or not if we convert their exe installation to msi??

    The main goal of following best practices and guidelines are to minimize the support calls.. that's why your customer is coming to you to repackage application..

    Every environment is different but the best practices are common.. it is not a standard.. - jagadeish 11 years ago
  • We'll have to agree to disagree. I think you are missing the point that the "advantages" disappear if it takes more time to implement and support the msi than to do the same thing with what the vendor gives you out of the box. - philologist 11 years ago
  • You have to think in long run.. Just becoz it supports silent installation, you are not creating msi and delivering as it is to your customer, missing out all the advantages of msi.. as a reslult.. your package does not have any good qualities .. What value you are adding to the application packaging life cycle here.. Just a silent command line.. There is no repackaging here..

    Everything takes time.. eating unripe bananas is not a great idea.. we have to wait until it becomes fruit - jagadeish 11 years ago
Posted by: rock_star 11 years ago
4th Degree Black Belt
1

Well , it depends on the time you have to package and type of package you are dealing with . We always tried to convert Legacy to msi ,however it is not always the case. If you able to get the same functionality of EXE with new created msi , if not then we would go with silent switch . Nowadays, We have time constraints too . Also there are few software which have customization tools so we should always try to go with them . Last , you can always come to itninja dot com ;)


Posted by: jagadeish 11 years ago
Red Belt
-2

First you should try to repackage the exe installation. In case if it is not possible to repackage the exe then go for silent installation.


Comments:
  • Thanks Jagadeish ll do that...:))) If you dont mind, can you provode your blog ID??? would like to follow - ontari.ontari 11 years ago
 
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