Software Deployment

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).

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

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.

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

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.

Brian,

What you also could have done is to just remove the msidbCustomActionTypeHideTarget flag bit for the CAs.

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

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.

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?

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.