Best Practices Question

Potential Issues using AutoIT as part of the Application packaging process

02/03/2016 1019 views
As a packager we have always used AutoIT as the exception rather than the rule.
What potential issues could there be wrapping all msi's and pre-requisites and post config  in an autoIT script.
For me we always judged each package on its own merits rather than automatically using AutoIT for everything.  IE custom actions, sccm functionality etc.

Any advice welcome
Answer Summary:
2 Comments   [ + ] Show comments


  • These are all very helpful. thank you. So to remedy this. Do we force a stop what you are doing from here on in. I dont believe it is an option to redo existing packages in this format. So do they just 'suck it and see' and remedy issues as they arise. What issues could arise if they are having to update one of these 'packages' using just Installshield and SCCM?
  • I expect you have standards defined. Enforce *not* using scripts, only after escalation which you have to give the OK to. If you can enforce this, and you set the hurdles high enough you will cut down on having compiled scripts wrapping packages.

Answer Chosen by the Author


It's easy to "botch" something into a script than understand a complex technology (msi) and implement it correctly. Added to that (correct me if I'm wrong) AFAIK AutoIT are compiled, and if you are really unlucky, you have no options of seeing what's inside, always risky.
In any environment I set-up, I avoid compiled scripts like the plague unless it's the ONLY work-around, and only after escalation (i.e. it's a pain in the ar*e to get the ok to implement).

Other than that, like VBScab has already stated, PS is a far better technology.

But to answer your question specifically...

Compiled Scripts are not transparent, i.e. there is no way to control exactly WHAT it does unless you have the original source-code of the script, and you know 100% that the source is really that what the compiled version was created with. When using (compiled) scripts, there is no way to ensure a "standardized" use of them. Before you know it, everything will be done using a script, even the "easy" functionality that the windows installer provides, therefore nullifying it's use in the first place.

Eventual changes to the OS may invalidate the underlying run-times that a compiled script require. Deployed (compiled) scripts that are used to retire applications are therefore at risk.

Very difficult to debug / error searching, unless of course you build logging into the compiled script (requires standardization) and then you would have two log files to search through, (MSI and compiled script).

I'm sure there are more, but at the moment i can't think of any more...

just my tuppence...
Answered 02/03/2016 by: Pressanykey
Red Belt

All Answers

What additional functionality are you after, that native MSI can't give you? Sending keystrokes to apps? "Editing" text files? I can't really think of much that AutoIT gives you that Powershell also does, with the added advantage that PS comes from the OS vendor, has many, many more example scripts and probably a far wider knowledge base.
Answered 02/03/2016 by: VBScab
Red Belt

  • our offshore team are implement this as a new standard and it is causing s issues wen trying to apply patched to adobe reader. they seem to be wrapping evert=ying in a script. it was always theexception rather than the rule with us
Always remember the old remark "KISS"
If you do not need to make something more complicated don't
Answered 02/03/2016 by: SMal.tmcc
Red Belt


Potential issues, that's a bit open.

I like the fact that you treat it as an exception. I really don't get why people do that for EVERY package, I spend a lot of time looking at massive vbs that essentially run an MSI silently. Seems a bit of over kill.

I liked the other comment about keeping scripts 'open', editable in a text editor is always a good thing.

So, potentially, things could go wrong, if its all wrapped up in a compiled script, its something you cant look at for any trouble shooting.

Answered 02/03/2016 by: Badger
Red Belt

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login


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