Build System Requirements for InstallAware

[Superfreak3]

I have a quick question. I'm getting ready to evaluate InstallAware and I'm just wondering what the system requirements are for my test build machine. Is there a specific version of .NET Framework that should be installed, etc.?

Any points to information is greatly appreciated!

[neillans]

There are no particular requirements - any pre-requisites needed will be installed for you when you install InstallAware.

[Superfreak3]

Thanks!

I guess I will be underway later this afternoon and hopefully will begin retooling our Wise installation templates in InstallAware sometime this week!

I'm sure I'll have questions.

[neillans]

If you have any problems, or questions, please feel free to post here on the forums, or e-mail support direct: support at installaware dot com and we shall do our best to assist!

[Superfreak3]

Excellant, thank you!

I have experience with InstallShield Developer 8 and Wise for Windows Installer 6.x, but I'm guessing that InstallAware is quite different. Or, will my previous experience assist traversing the learning curve?

[neillans]

The fact that you have braved both InstallShield and Wise should help - but InstallAware is still fairly different

[Superfreak3]

One thing, early on, that I do have concerns about is updating packages that have been previously deployed to the field. In reconstructing the installations in InstallAware, I would imagine different GUIDs will be generated for various components, etc. Will this cause problems in updating our Wise built installations in the field or should we recommend removal of the application as it now sits before installing any InstallAware built package?

[neillans]

Ideally, I'd recommend your suggest they uninstall the old build first - but if you know the GUID, you can set the "Upgrades product code" property and InstallAware will uninstall the old version for you.

[Superfreak3]

I don't know if I should have started a new thread for this or not, but here's the next question...

In looking over the various features of the various editions of InstallAware, I noticed the 'Import MSI/MSM Windows Installer Database', feature of the Studio Admin edition. If I take a currently compiled .msi created with our current tool, Wise for Windows Installer, how much rework will there be, do you think? I guess I should ask how reliable is this feature, since you have now way of knowing what garbage we currently have?

I'm wondering how close I can get to shortcutting the entire rebuilding of our installation by simply importing a current .msi.

Any info regarding this feature would be appreciated as well!

THANKS in advance!

[neillans]

It fairly reliable, but personally I'd recommend building your setup from scratch as it will be much more precise!

[Superfreak3]

I did quickly try the .msi import, but received an invalid .cab file error message. Our installation is completely encapsulated in the .msi, so I don't know if that is the problem. I would probably rebuild anyway.

I quickly looking at the New Project Wizard or under Build Settings of the newly created project, I see the following build types...

Uncompressed Directory Layout
Compressed Single Self-Installing EXE
Compressed Web-Based EXE.

Is there any way to mirror our current deployment method in that we would like everything in a single .msi with no external .cab files that I would guess appear if the first option above is chosen?

THANKS AGAIN!

[Gizm0]

The method you'll like to use, is Compressed Single Self-Installing EXE.

[Superfreak3]

When the .exe extracts, what do the contents look like, do you know? Is it a single .msi or .msi + .cab + any other files the install may need?

[Gizm0]

When the .exe extracts, what do the contents look like, do you know? Is it a single .msi or .msi + .cab + any other files the install may need?

All the process is done internally, so the user won't be confused. When you double click on the .exe, files are getting extracted on a temporary place, installation takes place and files remain cached for future used (maintenance plans etc).

[Superfreak3]

Yes, I understand that. I was just wondering if there was a way to simply create .msi files.

The reason we do this is that we install a client .msi file to a centralized location. Then we have an app that checks the version of the .msi from workstations in this shared location to determine if an update is needed/install should be fired.

If we encapsulate the .msi into a self extracting .exe, we would most probably loose this functionality.

To expand, we have a server install, which could probably be encapsulated. However, we then have a client .msi, currently installed by the server installation to a shared location, then called from workstations if code determines the installation is needed. I don't know that we could use something in this instance, which is wrapped in an .exe.