Does InstallAware conform to Microsoft Installer best practices?
Hi deployment crowd,
I hope that soemone can tell me (from own long-time experience) if InstallAware is a real alternative to InstallShield when I need a tool to build installations that meets the intention and the requirement of Microsoft Installer.
I am evaluating IA and discovered that you are not able to edit the MSI-Files directly, also the Sequences are not editable. It seems to me that the MSI-file is built at install-time based on the setup script.
In my opinion I loose completely the influence on what is going on during execution-sequence. It is like sending your request to a black box and hoping everything wil be alright.
InstallAware even gone a step forward and reinvented the wheel (MSI) by adding the possibility to completely install without Microsoft Installer technology. They call it "NativeCode" but I have no idea how it workes internal and there is no documentation about it. In general InstallAware seems a bit poor in documentation.
If you need native MSI-files for software distribution then you have to use a tool from InstallAware ("GroupPolicyWizard") that embeds your setup.exe within a strange MSI-file. So you can have a multi-language msi-file for instance. I thought that this is impossible, but IA did it ;)
Hope someone who knows InstallAware can tell his opinion about it.
My feeling is that InstallAware isn't a real alternative but a tool that reduces MSI-technology to absurdity?
Thx a lot.
-
How can InstallAware pin to the Windows 8.1 Start Screen or the Windows 10 Start Menu Live Tiles? This is impossible - as InstallShield says, Microsoft have blocked it. How come InstallAware are the only company doing this - how have they done it??? - vireshbhatia 9 years ago
Answers (4)
www.installaware.com/benchmark.asp
They contain links to the setup projects that are supposed to replicate these results. WiX samples are even included.
Has anyone tested and verified these claims? The claims do sound boastful...I would appreciate some precise feedback on the technical merits of each product; and needless to say, size and speed have always been two crucial factors in evaluating hardware/software performance.
Sorry not a IA user (I use installshield).
The only thing I can tell you is that I edit sequences all the time, if I did not have that ability the complexity of deployments would go up (and my sanity would go down:).
Just FYI, even installshield strays from MS installer standards. From what I have seen almost all of them do (Except Ora). Most of the time its to add ease of use or features. Installshield has ini edits, xml edits and advanced folder rights. All of which are not native MSI abilities (easy to tell with IS, you will see custom tables that start with "IS"...
I absolutely HATE MSI wrappers... Java, Lotus Notes etc use msi more like a wrapper then install tech. Completely messes crap up (try running java msi twice in a row and see if it works:).
Honestly I have not seen an installer tech nearly as competent, full of features and flexibility then MSI. IA's native installer code may help in some situations but it just seems too proprietary.
My opinion is keep to msi if you mainly support windows. Otherwise the tools needed to edit/create msi, is peronal preference and needs.
I would not stand for a solution that I can't edit every facet of an msi even if just direct table edits.
Comments:
-
Thanks for your replay. I use InstallShield, too. I know that IS extended the MSI-standard. But I like it that I can see what is going on during installation. I have full access to the .msi-files there and only the wrapper is a black-box for me. In IA as I said there is the whole execution sequence a black box. Also I have absolutely no influence on components, so how can they call it an MSI-Authoring-Tool!? For me it is a non-msi-tool but an script-installer. - Utnapishtim 12 years ago
-
The only thing I would guess, is that some things are editable but not in the way IS does it. Could be some odd tab, setting that does the same thing.
Otherwise, if I could not access sequences, features or components the tool is useless for msi editing (I am a repackager, not a packager if that makes sense).
Maybe the tool has the most features when making its "native" format???? - dandirk 12 years ago-
I'm relatively new to many of the applications mentioned here. I've been doing desktop support for many years, and would like to learn to repackage both legacy and newer applications (for SCCM, etc deployments). Any tips how how to learn, where to start, and what products to use? I've searched pretty hard and most of the time, I get directed to Flexora's website for their one week training for a couple grand $$$. Thanks in advance. - aprofit452 11 years ago
-
You could start with a book about Windows Installer. For InstallShield and InstallAware no (up-to-date) books are available. I was lucky and had a colleague that introduced me into this "rocket science" how it is often called.
If you just would create simple installers then InstallAware could be your choice, if you want to have full control about what is going on during installation you have to use InstallShield.
Of course you can also create MSI-Packages without the help of any Authoring Tool, just edit the msi files natively with the help of "Orca MSI Editor". - Utnapishtim 11 years ago
-
Yes their "native code" is the logical consequence of the "philosophy" (if there is one). All other is just a script installation. What would you as repackager say if you get such an InstallAware pseudo-msi file where you cannot access everything because it is encapsulated within a custom action... - Utnapishtim 12 years ago
-
InstallAware basically makes low-level MSI table editing look like assembler programming.
If the Windows Installer engine is being used to install, all actions which actually modify the target system are executed through the Windows Installer engine (to the extent where it is possible). The MSI file that contains all this logic is not the outer-most MSI file that is built by the Group Policy wizard - the GP MSI is basically a "Trojan Horse" which launches InstallAware's setup.exe file, which actually passes control to the inner setup.msi file when the statement "Apply Install" is called. You can easily see this real MSI file when you do an uncompressed build, and open up the MSI file in Orca. InstallAware actually embraces and extends Windows Installer technology, so with some low-level MSI (or shall we say, assembler skills), you can easily find the correlates for your script commands in InstallAware's MSIcode script as generated in the resultant MSI file.
For example, a single "Install Files c:\path\*.* to $TARGETDIR$" MSIcode command will create multiple component, directory, file table entries in your MSI file - all without you having to know anything about any of these underlying structures. This is what's so great and so much fun about InstallAware.
The whitepaper (www.installaware.com/msicode_scripting_technology.pdf) explains some of the details of the plumbing that makes this happen at length. Basically, InstallAware is a 4GL language/compiler which produces MSI files - and it works extremely well. The illusion of having a conditionally executing setup script is perfect, despite this being practically impossible using just Windows Installer. - Franz2013 11 years ago-
For me it is important to have full control over all components. So if InstallAware is generating components on build or install time, I have no control over these components because I didn't even know they exist.... - Utnapishtim 9 years ago
This is impossible as Microsoft has blocked it and reputable companies like InstallShield are therefore not offering a solution that does this.
How come InstallAware figured it out, and nobody else did?
Comments:
-
InstallAware know....
It's not rocket science - windows does everything with API calls to routines stored in DLL files, so running on a developer version of windows will give you a load of debugging information that leads to a way of implementing pinning. Installshield undoubtedly has closer ties with Microsoft so are less likely to go against the party line, whereas InstallAware have nothing to lose and market share to gain. It's no different to doing a binary edit of a Win 7 shortcut to enable the run as admin option. - EdT 9 years ago
InstallAware basically makes low-level MSI table editing look like assembler programming.
If the Windows Installer engine is being used to install, all actions which actually modify the target system are executed through the Windows Installer engine (to the extent where it is possible). The MSI file that contains all this logic is not the outer-most MSI file that is built by the Group Policy wizard - the GP MSI is basically a "Trojan Horse" which launches InstallAware's setup.exe file, which actually passes control to the inner setup.msi file when the statement "Apply Install" is called. You can easily see this real MSI file when you do an uncompressed build, and open up the MSI file in Orca. InstallAware actually embraces and extends Windows Installer technology, so with some low-level MSI (or shall we say, assembler skills), you can easily find the correlates for your script commands in InstallAware's MSIcode script as generated in the resultant MSI file.
For example, a single "Install Files c:\path\*.* to $TARGETDIR$" MSIcode command will create multiple component, directory, file table entries in your MSI file - all without you having to know anything about any of these underlying structures. This is what's so great and so much fun about InstallAware.
The whitepaper (www.installaware.com/msicode_scripting_technology.pdf) explains some of the details of the plumbing that makes this happen at length. Basically, InstallAware is a 4GL language/compiler which produces MSI files - and it works extremely well. The illusion of having a conditionally executing setup script is perfect, despite this being practically impossible using just Windows Installer.
