Potential Issues using AutoIT as part of the Application packaging process
Hi
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
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? - oreillyr 8 years ago
-
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. - Pressanykey 8 years ago
Answers (4)
Answer Summary:
Please log in to answer
Posted by:
anonymous_9363
8 years ago
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.
Comments:
-
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 - oreillyr 8 years ago
Posted by:
SMal.tmcc
8 years ago
Always remember the old remark "KISS"
If you do not need to make something more complicated don't
If you do not need to make something more complicated don't
Posted by:
Pressanykey
8 years ago
Top Answer
Hi,
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...
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...
Posted by:
Badger
8 years ago
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.
