Software Deployment

sounds like you're on the cutting edge with 64 bit installer. most of us probably haven't done that yet, but we all will if we stay in the field. why don't you tell us what you find? it sounds like you're using installshield.

Hi.
I need to make Microsoft Windows compliant package, which will be distributed through Active directory. Therefore I need to create a clean .MSI package for distribution.
The application, which I need to distribute, is running on an AMD64 system running on Windows 2003 R2 Server.
To create a package I do not have any special problems. Installing a package or using application is different story.
Well, at the moment I do discovered some things which can lead to 64 bit problems [8|]:

[;)] On the first place, for 64bit system you have to be careful where you start the installation from. For example, if you run installation from example popular Total commander (it is 32bit application) you need to know that OS think that you want to install 32 bit application. Therefore all targets directories are not on a regular folder (like c:\Program Files\...) but on a c:\Program Files(x86)\ folder.

[;)] Almost the same story is for registry settings. If you have 64bit application, which uses registry under HKLM tree, you need to know that regular 64bit application read HKLM keys under HKLM\Software\<Company>\<Product>.... On the other side, 32bit application read the same key under HKLM\Software\Wow6432Node\<Company>\<Product>.... So it is not the same key. Under IS12 you have to set 64bit flag for each component, who needs to change registry otherwise you will have problems.

[&o] For building package problems are as I've already said validation. As you can see in direct editor in InstallShield each CustomAction has a field called Type. This field is composed filed. It uses binary values to describe what kind of Action is. For example: VBScript stored in binary table has value 6, “execute action only once” has 256, etc. InstallShield12 has also one flag for VBScript CustomActions using 64bit scripting. Its value is 4096. You can see in Custom Action properties that when you turn on this flag dimmed property “MSI Type number” is increased by 4096. Until now it is all OK. But when you try to build the package using “full windows validation”, at the end you got mentioned errors: [font="Courier New"]ICE03 ERROR Value exceeds MaxValue….
I’ve checked IS solution file (.ism file I have is in XML format) and “_Validate” table shows max value of 4095. It is obviously an IS12 bug – IS12 do not put regular max property value into that field. Until 64bit it was ok but for 64bit scripting it is too small. Also Microsoft’s validation file (darice.cub), which comes with ORCA or MSIVAL2 application reports the same error. Therefore also Microsoft has a bug in their validation files.

That is my short description [8D].

Best regards
Andreo

Andreo, that sounds tough. glad it's you on the bleeding edge (for now) [;)]
as far as the MaxValue error, perhaps you can alter the Schema in Orca and change the Custom Action Type column to a long int? Then it might be able to handle the greater value. Or maybe you could try a MaxValue of, say, 8192 in the _Validation table?

good luck, let us know how it goes!

Owen

Hello Owen.

Actually, with help of Michael Urman - Software Engineer - Macrovision: InstallShield Windows Team, I got a workaround:
The problem lays in IS templates files. InstallShield uses this templates for building .msi package from .ism solution file. After some corrections in these template file(s) (Support\0409\ISMsiPkg[Large].itp) I do not have errors any more.

Whole conversation is reached in InstallShiled community.

Best regards
Andreo