Hi All,

On running Full MSI Validation Suite in Orca (v3.1.4000.1830) I have three remaining ICE Errors that I'd like to fix:

ICE03 Error Value Exceeds Max Value; Table: Custom Action; Column: Type; Keys(varies......)

I read and understand the error as the value of the number in the Type colum is too large; the three offending Type numbers are: 8193, 8243 and 11265.

I did some googling, visited MSDN, etc but can't seem to find any information on the values of these Custom Action Types: 8193 & 8243.

Custom action Type 11265 refers to hidden data/passwords/security which figures as this is an AV product with passwords.

Any ideas?

Brian
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
Don't bother fixing vendor MSIs, if they work they work!

However, the Type column is a combination of the type and options.
http://msdn.microsoft.com/en-us/library/aa372048(VS.85).aspx

If you use InstEd it will actually show you the different options which is part of the Type number(s).
Answered 11/04/2008 by: AngelD
Red Belt

Please log in to comment
0
Don't bother fixing vendor MSIs, if they work they work!

Sorry, I disagree there. Most estates I've worked in have fixed ICE errors (even been one place where they wanted warnings fixed lol!) and the ones that haven't I've tended to fix them anyway as that was what I was used to as "best practice." I appreciate one person's best practice isn't anothers though.

Anecdotally I believed these estates to be more stable but that's probably just wishful thinking :o)

Thanks for the heads up for InstEd though.

Brian
Answered 11/04/2008 by: fritoz
Orange Belt

Please log in to comment
0
Hi Brian,

I think you will see most packagers do not fix vendor's MSI.
For repackaged ones yes, that is recommended.

But I must say it sounds strange that you get ICE03 on the CustomAction.Type column value.
Can you verify which schema the MSI is created with, could be for Windows Installer v4.x and in that case download Windows Installer 4.5 SDK which has a newer version of ORCA. You could also use InstEd for validation as it also includes the new CUB file for validation as the SDK does.
Answered 11/04/2008 by: AngelD
Red Belt

Please log in to comment
0
Hi,

If I browse to the _Validation table the Max Value in there is 4095. Changing this value to a value higher than the largest CA Type solves the ICE03 Error.

However, this seems like a bot of tricksters fix. I validated in InstEd and used various validation sets and browsed to the installed CUB files but still get the error.

I'm downloading the 4.5 SDK out of curiosity. I'll document the three ICE Errors as an exception to our standards.

Thanks for the input.

Brian
Answered 11/04/2008 by: fritoz
Orange Belt

Please log in to comment
0
i also tend to steer clear of fixing vendor msi errors. often vendors do not follow strict windows installer based guidelines and fixing their ICE errors can actually introduce worse errors I have seen this on many occassions.

i think you will find a majority of the repackagers here tend to avoid this as well. in saying that I am all for fixing your own ICE errors.
Answered 11/04/2008 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment
0
Brian,

What you also could have done is to just remove the msidbCustomActionTypeHideTarget flag bit for the CAs.
Answered 11/05/2008 by: AngelD
Red Belt

Please log in to comment
0
Thanks AngelD just doing my sums and subtracting the relevant flag bit value :o)

Perhaps I should clarify:

I fix all ICE errors in my MSIs and have taken this wherever I've gone. I've been fortunate enough to have worked in (and helped introduce where necessary) strict packaging and particulalry testing standards. In this circumstance we fix all ICE errors and if the package is signed off at UAT and pilot testing then the package goes as is. Should any package fail testing we have staged backups of the MST (or MSI in our own packages) taken after each ICE error fix up phase (e.g. after ICE03s, after ICE64s, etc) that we revert back to for a working package.

Maybe I should change, save myself some time and drop fixing ICE Errors in vendor MSIs.

I'd like to see the results of a poll on this, though from this post it appears I may well be in a minority of 1 lol!

Brian

edited for grammer
Answered 11/05/2008 by: fritoz
Orange Belt

Please log in to comment
0
Now that I hav returned from my break, I'll wade in with "I almost never fix vendor MSI ICE errors, either."

I apply (within reason, obviously) the same view that I take when re-packaging, i.e that what I put out should, as far as is reasonably possible, replicate what the vendor's package does. As we know, vendors are cute at wriggling out of their support responsibilities and I have known some disown installs which have had transforms applied. I kid you not. As I say, I do take a pragmatic view about certain practises but in general, if their MSI fails validation, so be it.
Answered 11/05/2008 by: VBScab
Red Belt

Please log in to comment
0
What is the general recommendation for vendor supplied MSIs that conflict with each other regarding component rules etc? Change via a transform or leave as is?
Answered 11/06/2008 by: LouisW
Senior Yellow Belt

Please log in to comment
0
Always transform to retain the original vendor MSI.
Regarding conflict it would depend on the conflict. For same component with different GUID (ComponentId) then fix it.
Answered 11/06/2008 by: AngelD
Red Belt

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