Installer with X64 and x86 in one

[InterWAS]

Hi,
i have the same issue, and i think that the best thing to do, IMHO, is change the Application Requirements page,
in option "64 bit operating system (puts setup in 64 bit installation mode)" change to a combo with 3 options:
"32 bits operating system only"
"64 bits operating system only"
"Mixed - 32 or 64 bits operating system"
each option will enable/disable parts of the check scripts acordinaly.

thanks,
Wendel.

[mills]

Wendel,

I'm taking this as a feature request? This may be possible, but could complicate things a bit.

[JohnGalt]

Please do take it as a feature request. The way it is right now is a pain in the butt and causes all kinds of frustrations when you try and hack it.

It also needs to know how to uninstall these properly on uninstall of the app. Right now you can have all kinds of issues if you're not really careful and modify the default scripts with apps that won't properly uninstall anymore because pre-reqs aren't there etc. (you validate their presence on uninstall which is not a good idea)

[mills]

Note taken. This will change quite a bit of things, like requiring two Runtimes views to select x86 and x64 specific runtimes.

But, I agree this is a good idea and passing this along to our product managers.

[J. M.van der Kolk]

I have to concur. It is too complicated to create an installer that supports both 32-bit and 64-bit targets.

My suggestion to InstallAware for a feature request:
Create another set of runtimes that supports the combination of 32-bit and 64-bit. Those runtimes would install the appropriate runtime depending on the target environment (32-bit versus 64-bit).

[giaviv]

Dear J. M.van der Kolk,

Have you tried using the Set 64 Bit Mode command? Could you please explain why you found it difficult to use?

Thanks!

[JohnGalt]

It's really simple:

1. There is no case where I don't want x86 and x64 versions of pre-reqs. There couldn't possibly be case where that would be desirable, because even if my app is x86 only, most of the pre-reqs require you to install the proper version on the machine regardless of the app that is being installed, and will fail if launched causing a rollback of your installer.

2. As it stands now if you add both x86 and x64 to the same project without manually editing scripts you end up with an installer that does not work because the pre-reqs will attempt to install even if the version of windows is not applicable.

3. The installer checks to make sure that pre-reqs are installed before uninstalling. Sorry but this is just a silly default. People uninstall these pre-reqs all of the time and even have to uninstall first (i.e. SQL Server if there is a database attached that is going to be uninstalled by your app you have to uninstall SQL Server first, then uninstall your app because it's not possible to chain uninstall SQL Server). While there may be an edge case where you need the pre-req to uninstall completely, it would be stupid of anyone to write an uninstall that would fail and prevent the app from uninstalling because of a pre-req not being there.

Thus:

1. The Pre-reqs should be both versions and on web download download the correct version for the machine and only install that one correct version and not even try the version that is not applicable. If it's a cd install, it should include both and do the same on install. It's silly to do it any other way and requires a massive amount of scripting and hacking and testing to work around this non-sensible approach.

2. See #1 of my thus:

3. Remove the check on uninstall by default. Make it easy for someone to edit the script and do something stupid if they want, but don't make that stupid behavior the default!

I don't know why, but installer developers don't seem to get the process of install. I've been telling MS about these things for years with Windows Installer, I've tried in the past to tell Wise and InstallShield and now I'm trying to tell you guys. Your approach is wrong.

The purpose of an install is to:

1. Get any pre-requisites installed that are necessary for the successful installation of the app ON THAT MACHINE. (it isn't to try and install stuff that will fail, either because of it being the wrong version for that machine, or because it's already installed! (ms is famous for mdac failing and cancelling your install if mdac was already installed!))
2. Install the application so that it's in a working state.

The purpose of an uninstall is to:

1. Get the damn app off my computer at all costs!
2. Give your ex-customer a friendly handshake on the way out and not hurt their computer in the process.

Your approach fails these purposes. Please fix.

The power of your hybred install technology is that now I can work around the windows installer silliness and actually deterministically install these pre-reqs based on install options. But of course I can't do that right now without having to write a ton of scripts. Further the power of the hybred install is that on uninstall I can uninstall pre-reqs (i.e. our own instance of SQL Server Express edition that needs to be removed) but of course I can't do that without having to write a ton of scripts. (and I can't do either of these things with Windows installer because it's busted)

You have an opportunity to really get this stuff right and build a system that is different and WAY BETTER than everyone else's because you understand the PURPOSE of an installer. You should go back to all of your assumptions that you (I'm guessing) got from looking at everyone else's installer technology and copying it, and measure your decisions against the logic outlined above, instead of what those companies have done (wrong).

[sinan]

You don't have to write a ton of scripts to achieve the objectives you have in mind. In fact, you can achieve all of those things with just a few If...Else...End's here and there around your existing runtimes.

For example, if you want to block pre-req checks on an uninstall, just test whether MAINTENANCE is TRUE or not in your prereq block. Its not a ton of script - just two lines of code around the entire block.

However, as I am sure you will find out as you start customizing the scripts, it is VERY difficult to come up with a GLOBAL solution that works for ALL customers in ALL scenarios. This is the REAL workload in what you are referring to as "a ton of scripting".

The scripting required actually is minimal. Here, our MSIcode helps you offer the most flexibility for your customers. MSIcode is our offering to you in reducing your workload as far as possible.

Unfortunately, the problem is coming up with the GLOBAL LOGIC that works in all scenarios with just a single click. I do hear you - and I would like to still try and offer a GLOBAL solution that would work for ALL customers in ALL scenarios. Now, in such consideration, please try to answer the questions below if you have any well-thought solutions:

1. 32 bit - 64 bit Issues:

a. Bitness Requirements:
Some 32 bit runtimes can install on a 64 bit OS as-is. Some 32 but runtimes can NOT be installed on a 64 bit OS at-all. Of course, all 64 bit runtimes can only be installed on 64 bit OS's.

b. Application Requirements:
An additional complication however is that some apps will NEED the 32 bit version of a runtime even on a 64 bit OS, depending on the bitness of the application. We cannot make any assumptions on application bitness when preparing our runtimes.

c. Payload Requirements:
A customer may want just the 32 bit of a runtime and never the 64 bit version of it, or vice versa, due to a need to optimize the payload size with a single build option. Therefore, a single check-box to "magically" install the correct bit runtime will often end up doubling payload size.

Note that our partial web deploy already covers web downloading of just the required bits - it seems that you might not be aware of this presently.

2. Maintenance Mode Issues:

a. Application Requirements:
A custom application may be required to run at uninstall time. In this scenario if the application requirements have already been removed, this will of course fail. The clean-uninstall will therefore also fail.

b. Server Requirements:
Similar to running a custom application, a server script may need to run, say on an instance of SQL Server, to do some clean-up work, or any other kind of processing. This will again break the clean-uninstall.

c. Shared Technologies:
It would of course break tons of other applications already on the system if we force the removal of prereqs at uninstall time. For example, removing any version of .NET etc. would just give your application a very bad name!

Note that our current design philosophy has been to provide the safest install and uninstall process with the highest possible success rates on both. We have tried to isolate you from as much of the manual coding as possible, except where we believe YOU DO NEED to make a decision based on your requirements (as reviewed above).

Edit: You indicate that you want to get your application off of the target computer at all costs. If this is just deleting files, this can be achieved by just deleting your application's folders (as most users do, and eventually end up regretting). Also, you can force the uninstallation of any existing InstallAware setup, bypassing the prereq block, using this command line:

Code: Select all

setup.exe /s MODIFY=FALSE REMOVE=TRUE PREREQ=FALSE

With a standard InstallAware setup script (both native and MSI engines), this will have the net effect of forcibly skipping the prereq block, achieving your objective. You could even add one line of "Run Program" to your own uninstall routine if you detect/suspect any issues with prereqs to do this programmatically.

Again, InstallAware is so versatile - we really do give you all the tools you need to achieve anything you want.

Looking forward to your feedback all the same.

[ohali]

Just a short conclusion, take it as a feature request (which will probably be supported by most of your users):

Provide additional runtimes that will transparently install the correct version of the pre-requisite. So that we can choose (for example):

microsoft visual c++ runtime 9.0 (includes atl and mfc) service pack 1
microsoft visual c++ runtime 9.0 (includes atl and mfc) service pack 1 (x64)
microsoft visual c++ runtime 9.0 (includes atl and mfc) service pack 1 (x86 or x64)

This will not do any harm to any user, it will just add additional comfort and a better argument for selling InstallAware.

An increasing number of developers has to provide a setup for both x86 and x64 platforms, and I'm sure, all of them would appreciate this solution.

[giaviv]

Dear Ohali,

Thank you for your input. Please note that creating additional runtimes is a very easy task - here is a tutorial on how to do so:
http://www.installaware.com/installawar ... s_view.pdf

[ohali]

Thanks for your response.

I know that it is easy to build your own runtime and I've done so before a couple of times.

But the question is: Why should I and hundreds of other developers do so, if it would be so easy for you to provide a solution out-of-the-box? It should it be in your own interest to provide a software where everyone says "wow, that is easy".

At the moment you are stating at your website

One Click Pre-Requisite Installer

,

Painlessly install complex application runtimes

and

Absolutely no manual configuration or tweaking is required.

. But that's not true.

For eaxample, if I have to install the C++ runtime 9.0 as a pre-requisite and my setup should work on x86 and x64 platforms I have to tweak the scripts or build my own runtime. Is that painless? No, it's not. Of course it's possible to do so (and that's great!), but it's not painless.

If I read the comments from the InstallAware-Team on user requests here I'm always thinking: "Wow, it would be so easy for you to provide a great software. Why don't you do so?".

Or is there any (!) reason not to provide the additional runtime I (and several others) are asking for?

[giaviv]

Dear ohali,

Please note that many runtimes are already shipped with InstallAware and are installable painlessly. We continuously try to keep up and create new runtimes (for example, we recently added SQL 4 CE and IIS 7.5 Express). I apologize for the inconvenience, but there is a plethora of runtimes out there and obviously adding support for them all would be a ridiculously long task. As such, we allow users to create their own runtimes in a way that in my experience, is easy, straight-forward and painless.

[Obliterator]

I would love this feature in the next version of IA too

I think you should take a look at the whole hybrid x86 and x64 install experience.
It works as it stands for sure, but I think there is a little room for improvement.

I agree with the thrust of comments above. I want the installer to install the appropriate runtimes for the target OS (both runtimes where necessary, i.e. where x64 version also requires x86 version). Downloading only the runtimes necessary as webmedia blocks. During uninstall, I don't care if the runtimes are present or not. Nor do I wish to remove them, just remove my app without forcing the user to reinstall any missing pre-requisites.
I'm sure the majority of developers want exactly this functionality out of the box. I state this without any statistics to back me up

I have long since accomplished hybrid installs with IA9R2. With minor modifications to the scripts it works very well indeed.
My setups can provide support for both x86 and x64 runtimes as I require and I avoid demanding installation of pre-reqs when uninstalling - so all is fairly good in the world of IA! In fact kudos to the IA team here, the runtime selection, bundling and automatic download feature is factors beyond your competitors.
IA allowed me to accomplish this long before I could do it with another installation package we used to use (but no longer speak of)!!!!

But I'd still love hybrid support to be better handled out of the box. If you're not careful you can fall foul of problems. For example, if I subsequently add other runtimes - the UI can change the order of existing runtimes in my script and break things. So you need to look at the code carefully after adding runtimes.
A further gotcha is the standard scripts actually change the state of 64bit mode back to 32bit. So you have to watch out for this.

I'm used to being spoiled by IA and not having to work or think about things like this!
I would love the runtime selection dialog to list each runtime with 3 simple tick boxes. One tickbox to bundle x86 runtimes, one for x64 runtimes and the third to state if the runtime is required during the (un)installation process itself (controlling if that is required as a PREREQ during uninstallation). I simply tick what I wish to support and IA would handle the rest. Ticking x64 would automatically force x86 to be ticked for those components that need it. It would bundle webmedia blocks as required and conditionally install/require them as required. In all scenarios the runtime itself would never be uninstalled by my setup.

I would also like better ability to read/write from 32-bit and 64-bit registry locations. Ideally, choosing which location I'm targetting in the registry commands themselves. I realise I can accomplish this by changing 64 bit mode, but setting this around the registry commands seems to have no real effect - only around the Apply Install command. This makes access to both regisitry locations in a hybrid setup quite difficult without multiple apply install commands (which is advised against).

Finally I've had issues bundling DIFx drivers for hybrid installations. Again its possible with simple workarounds in the scripts but I'd love this to be supported natively out of the box.

Just my thoughts for what they're worth.
Keep up the good work! IA really is a great a product and saves me hours compared to our previous tooling.

[Obliterator]

Ooh and whilst your looking at runtimes...

Could you make the builder for the media blocks match the case of their filenames?
Presently mediablocks are built with all lowercase filenames, rather than those specified in the media block settings.
This means downloads fail from case-sensitive unix based servers unless I rename each file manually or remember to edit the mediablock URL to lowercase accordingly.
Also why does one byte of each mediablock seem to change each time its built? This causes my source control to think the file has changed when really I don't think it has. I would love the files to remain unchanged (unless their contents change obviously) or for IA to have an option to only "Build if missing" and not delete existing media at the start of a build.

[giaviv]

Dear Obliterator,

Regarding your Web Media Block issue, you can tell InstallAware not to rebuild a block in a build (double click the Web Media Block declaration).

Other than that, I truly value your input!