Another WISE user considering switching.

[Thona]

Let me start saying that so far I am propably the world's most pissed install maker user. I consider Installshield to be the buggiest product every released for professional developers and am sadly very disappointed from WISE' upgrade policies (as in: they simply do not make their job - no support for .NET 2.0 at this point, and we have to ship in january).

I am now in the move to abandon WISE and consider moving to either InstallAware, or WIX. I have a number of questions and hope you can and will answer them satisfactory I would LOVE to finally have an install builder that actually DOES IT's JOB without being utter crap or not really maintained.

Le tme also say that while I do not really like your scripting approach from a purity point of view, I do really see the advantages - well done to work around the limitations of the MSI engine. VERY well done.

Ok, here come my questions:

* What is your update/path policy? I mean, WISE is known by me for not realeasing upgrades for LOOONG times, and this is not really acceptable. We DEPEND on an install builder to ship products, and bugs should be fixed asap.
* Can it be your visual designers are limited? I just am doing my first steps, but I did not find any way in the .NET assembly designer to set conditions or assign assemblies to features/components. I had to switch to code-view to put them into the "proper place" for a component/feature only. NOT that is that complicated, just trying to find my way around.
* You deal with features, and hide the components (on MSI), as it looks like. What about features that SHARE a component - how should this be modelled? Imagine a Feature A-B (A, subfeature B) and A-C, and both rely on a component installing some assemblies in the GAC. I need this to execute if EITHER A-C OR A-B are selected, but not if only A-D is selected. I could do so easily in Installshield (where I could assign components to features), and pretty hard in WISE. HOW would I do this with you?
* What about merge modules? Do you provide support for CREATING merge modules? We are in the developer tool market, and routinely craete merge modules, too, and I would LOVE to make this from one location.
* What about - Soruce control? Is there any integration? And plans for integration? I am just asking here - it looks easy to just put the directory under source control
* Graphical work. What is the suggested licensing approach for our designers? You offer really good greaphical options, and I can see us asking our designers to redo the dialogs in our own way. Bad news on this is that this would require a total license for them - or is there a way to JUST give them a licensed deisgner? Remember, I am talking about JUST changing the dialogs.

Seems like you have done a decent job in providing an alterantive to WISE and Installshield. I am satisfied with nearly everything in my development environment EXCEPT install building, and I would LOVE to find a home for this.

[sinan]

I understand how you feel. InstallAware tries to provide the best experience for setup developers, and we can do this because installers are our core business. For instance, we supported native installs of .NET 2.0 48 hours after it was released. This support was available free of charge for all customers (including trial users) in the form of a plug-in update pack. You say below that Wise doesn't support .NET 2.0 at all so far, and InstallShield only recently added support - and you have to pay for it.

About your specific questions:

* We are pretty aggressive about fixing bugs, resolving issues, and coming out with new versions - just browse around the forum and see for yourself.

* The heart of your installation is the setup script, and the visual designers do a great job of maintaining it for you visually. For some kinds of tasks though, you need to use the setup script - as in what you say above. You can easily achieve what you want using the Get Component State and If script commands. Notice that unlike InstallShield, InstallAware's script is the entire setup project. The visual views are not divorced from the setup script (as they are in InstallShield) - they simply manage it for you automatically. This means you are in full control of what you want to do at all times, nothing happens behind the scenes, and you can build extremely customized setups.

* Unfortunately, we do not support creating merge modules at this time. If you want to share code between your InstallAware projects, the recommended way is to use the Include Script command. I do see what you mean below about providing MSM to your users though.

* While I cannot provide a timeline, we do have plans for source code integration (and merge modules too, of course). How many of these gets implemented and how soon I cannot say though...because our focus is on advancing the state of the art in installers (better compression, better scripting, better web deployment, better user interface), we occasionally do sacrifice conveniences here and there.

* You really should make your own custom dialogs - this would be great. You can let the designers use the user interface editor as long as you purchase a Studio Admin edition.

Out of curiosity, what development environment do you use?

[Thona]

Very nice answers - so different from what I am used from Installshied and Wise I particularly like your answers about fixing bugs. Btw., newest answer from Wise: .NET 2.0 support is scheduled for Q1 2006. Now THAT is what I call ignorance. I mean, what about customers who WANT to ship products? We are now basically forced to look for alternatives.

Ok, the only real negative is the merge module for our customers, and that is something really minor that we can handle. We have been thinking of abandoning the merge modules for the time being anyway.

I seem to really like your scripting approach. It is very unusual, but it is sort of really interesting. Smart thing.

We use Visual Studio 2005 at the moment, heavily expanded by some DevExpress utilities for better editing. We are VERY satisfied with this. We use currently Vault as source control, but will soon replace that - not because we are not satisfied, but because we have our own VCS in development as a side-product for a document management system. We use Innovasys for documentation and hate it - replacement for this is something we look for aggressively, but the situation there seems to be worse than in the installer market.

You missed one question and I wantto re-emphasize it:

* You deal with features, and hide the components (on MSI), as it looks like. What about features that SHARE a component - how should this be modelled? Imagine a Feature A-B (A, subfeature B) and A-C, and both rely on a component installing some assemblies in the GAC. I need this to execute if EITHER A-C OR A-B are selected, but not if only A-D is selected. I could do so easily in Installshield (where I could assign components to features), and pretty hard in WISE. HOW would I do this with you?

This is something I am facing at the moment during my trials. I have this type of "shared component" thing that is either installed due to user demand, or because of another feature requiring it. How would you solve this?

[sinan]

I already replied to that, but I guess it wasn't clear enough. You will use scripting to achieve that. You will first use the Get Component State command to determine if particular features are selected or not; and store the result in variables. Then, you will use the If command to analyze those variables, and take appropriate action in your setup script based on component selection states. So something like:

Code: Select all

Get Component A into VARA
Get Component B into VARB
if VARA is True then
  if VARB is False then
    Install Files ...
  end
end


in pseudo-code, of course.

[Thona]

Ok, got it

The "old" scripting approach Looks familiar to programming. VERY nice approach.

Ok, I am going to test things now. I make a new installer for one of our products and then send it to our graphics people and the result to a selected number of customers for feedback. I think they will love it

If they do, and no problems arise that I can not work around, it should be a go.

[sinan]

Great

The beauty - or rather, one of the beautiful things about InstallAware is that it combines the benefits of a state-based installation system (Windows Installer, with its self healing and advertising support) together with the power and flexibility of a scriptable installer.

When you build your setup script, you automatically get a legal MSI database that works to allow state-based installations, while still offering you the power of scripting using our Genuine Scripting for Windows Installer tech.

Enjoy!

[Thona]

Yah. slowly getting it. I would love, though, if the Feature/Component-separation would be in InstallAware. I always found this to be REALLY handy, that I could get in and actually manually define my components. Especially in very modular systems your current approach is a little tricky. It would be logical to show certain files as a separate "feature", but then the user should neither have a choice to install them, nor should he even SEE them.

To give you an example: the Setup I am making now has 5 tools you can install. They are optional. If only ONE is installed, a long list of additional files needs to be installed (third party ui components we utilize). In Installshield I would set up a component for this additional support files (or multiple - we talk of three suppliers) and link the component to all features requiring these files. Here, now, things get a lot more complicated.

Do I get this right that there is no "install on first use" for a feature?

[sinan]

To address the first problem, create a new include script file, and then use the Include Script command to call that script from your main setup scripts in each project it is needed. That should help address the complexity. I would do the tests in the main script (if this that then...) and then in the shared include script I would add in all the necessary commands - Install Files, Write Registry, Create Shortcut, etc...this would be the InstallAware way

About the second question, you are right - you can install the entire product on first use using Install Advertised, but not features.

[Thona]

Is it planned to incorpoate feature advertising?

[sinan]

In all honesty, no - we haven't had any requests for it so far. I would also have to ask our Product Team how advertisement at the feature level will go with the Genuine Scripting InstallAware powers MSI with. So, no promises on this one at all!

If this is a must have for you right now, you could create another InstallAware setup, install it advertised, pack it up in light mode, and add it to your main setup, and run it silently if your install on first use feature has been chosen to be installed. So a workaround is available, but no doubt, it will take a bit of extra effort.

[sinan]

Thona,

The fundamental fact today is that InstallShield was sold to www.macrovision.com and Wise was sold to www.altiris.com; both Macrovision and Altiris are large companies with hundreds of products. If you go to their website, you will be hard pressed to find information on InstallShield and Wise.

The original founders and creators of InstallShield and Wise have sold their business to these large companies and are no longer in the business - so it is unlikely that the products will see any evolution and will probably slowly die inside large organizations. I recommend that most InstallShield and Wise users should switch to other install technologies - regardless of what they choose, they need to move away from InstallShield and Wise. Note that the Wise website has not even changed in two years...

Sincerely,
Sinan