Hello.

I'm making a .msi package of my product using InstallShield12. The product will run on an AMD64 Win2003 Server R2.
During installation it is called some custom actions. In a package CustomActions are signed with x64 flag therefore all values of CustomActions type are incremented by 4096 (stands for x64 scripting). Otherwise all custom actions are Type 6 - Function from VBScripts stored in a binary table therefore in my package all have in a CustomAction Type value 4102.

The package itself is normally installable, but when I try to validate it I got error:
ICE03 ERROR Value exceeds MaxValue; Table: CustomAction, Column: Type, Key(s):...

I run validatation on a regular way:
msival2.exe Pkg.msi "C:\InstallShield12Projects\darice.cub" -l Vallog.txt
Darice.cub file exists.

If I open my .msi file with Orca in _Validation table max value is 4095. For me, it looks like that IS12 know for x64 flag at design time, but at build time not. Also, darice.cub validation file do not understand x64 scripting type, too.

Where is the catch here?

Thanks in advance

Andreo
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
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.
Answered 11/27/2006 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
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
Answered 11/27/2006 by: jamsek19
Orange Senior Belt

Please log in to comment
0
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
Answered 11/30/2006 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
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
Answered 12/01/2006 by: jamsek19
Orange Senior Belt

Please log in to comment
Answer this question or Comment on this question for clarity