Software Deployment

Personally no, I don't fix any ICE errors which already exist in a vendor MSI when creating a custom transform - I just make sure that I haven't created any new ones in the mst... [;)]

Some vendor MSIs have literally thousands of ICE errors and I find it amazing that the apps even work!

but when we import the repackaged MSI +MST in conflict solver database it performs a validation check and refuses to import if finds any validation (ICE) errors .

To circumvent this issue i have to uncheck ICE Validation in my conflict solver before importing a repackaged application .

Is this a point of concern as we have to sometimes leave errors as is in vendor MSI's ?

PS: I am using Admin Studio 5 for packaging
Cheers ,
V

Hmmmmmm we don't conflict check here so it's not an issue. So...

1) Fix vendor ICE errors as part of the packaging process so you can import your packages into conflict solver

2) Don't fix vendor ICE errors and continue with your current workaround (turning off the ICE validation check before importing transformed vendor MSIs)

If it was me I would continue with option 2 and not worry about it. I know this isn't much help but it's a decision for your company to make weighing up the time it may take fix vendor ICE errors vs the risks involved with leaving them.

Some packagers don't even fix ICE errors on snapped MSIs arguing that as long as it installs then it is OK. I would always recommend fixing as many ICE warning and errors as possible for your own packages, and not worry about vendor MSIs.

I guess the most important thing in any case is to make sure your QA and UAT procedures are sound. As long as you can deploy your package, it works correctly and uninstalls relatively cleanly you should be fine. Leaving vendor ICE errors may mean your app doesn't (for example) repair properly or advertise - you'd have to address these anyway to get the software to install and work to your company's requirements.

Sure you will get different opinions from other members though - good topic for discussion [:)]

Cheers,
Rob.

I generally try to fix all errors, but ignore warnings.

In a perfect world I'd address the warnings too, but the business gets impatient enough when a package takes more than a week to complete, so in the end I have to settle for a 90% complete solution rather than 100%.

I do run into occational problems trying to create the package in policy (MSI's are validated here as well) but the majority of these problems in the past have been related to ICE errors rather than warnings.

i never touch vendor issues, often vendors dont follow enterprise standards and as such fixing errors can result in damaged packages.

Many vendor supplied MSI's simply suck. I'm the annoying guy who makes a big stink with their support staff. I usually start off the conversation by telling them that I don't think I have their official release, but a pre-release because of all the errors in their install. It can't possibly be the install that has passed their QA process... (I love listening to them stammer) [;)] It has never gotten me anywhere on that particular release, but it's funny how the next version seems to get better.

I strongly recommend to all packagers that you complain to vendors about ICE errors and applications that do not follow Windows standards and consequently only run under Power User or Admin security levels! It won't help you in the short term, but it WILL have an impact on the next version. By complaining, I brought our biggest nightmare app to an example of a perfect vendor MSI in only 2 releases.

That said, I fix the vendor MSI's with a VendorCorrection.mst transform, but only to a reasonable degree. I draw the line when the corrections start involving major changes to the app. It's a judgement call. Dot the I's, cross the T's, maybe make a sentence or two gramatically correct, but do not rewrite a paragraph.

Thanks to all of you for participating in this discussion .

Looking at response from various people till , I think its a good practise to resolve ICE errors for Vendor MSI's also . However the errors resolved should not break the package or change the expected functionality . Last but not the least respective Company stand on this particular issue also is a key factor .

Is anyone aware of any pointers to any best practises published by microsoft / installshield etc .. for the same ?

Looking forward to more response from other members of the group .

Cheers ,
V

ORIGINAL: VikingLoki

I'm the annoying guy who makes a big stink with their support staff. I usually start off the conversation by telling them that I don't think I have their official release, but a pre-release because of all the errors in their install. It can't possibly be the install that has passed their QA process... (I love listening to them stammer) [;)] It has never gotten me anywhere on that particular release, but it's funny how the next version seems to get better.


Hahahahaha, I never thought of that tactic but it's always worth a try as the odd vendor does listen.

By default I don't resolve them beyond reasonable endeavours. By that I mean that when there are glaringly obvious ICE errors that are easily resolved and that do not have an impact on the general application, I fix those in my transform. However, modifying such errors generally can mean voiding the warranty (albeit limited) on the vendor packages.

Import vendor packages without ICE validation. It sucks, but that's how the vendors do it.

I agree with VikingLoki that it does help to complain to the vendors. I never used to do ICE validation as long as the MSI works, but these days, no way (except for snapshots where there are tons of ICE33's that can not always be added into the Class, Typelib and ProgId/AppId tables).

Stefan

I agree with StefanP on this one. I generally ignore ICE33 warnings unless the solution is completely obvious. The most common ones I see tend to be related to undefined AppID's, CLSID's and TypeLib's etc...

Maybe one day the vendors will get it right! (Oh, did a pig just fly past my window?)

I use AdminStudio 6.0

M

Hi

I'd like to stand up for some software vendors being one myself regarding validations:

We adhere to the following policies when creating our msi's:
1. NO ERRORS ALLOWED. Most general errors are simple to fix as long as you understand the msi tables.
2. Warnings should be fixed where possible, but note you get more validations warnings from Microsoft merge modules????

In reality packaging is always regarded as a trivial exercise and often is not given sufficient time at the end of the development schedule, we try our best guys but sometimes you can't fix everything.

DRS

You are right we shouldn't be too hard on vendors...

If all vendor MSIs worked without any problems then packagers might be out of a job!

Good one. Well For me, my own authored MSI have to be error free. And I agree I could care less on the ICE33 warnings on the TypeLib, ProgID and AppID classes. However, sometimes these vendor MSI's are full of errors. While I'm careful enough, only on a very rare occasion do I try to fix a known error. I'd rather leave them as they were, then trying to fix the errors and ending up "disturbing" the core installer.

Hi All.

How about we have an extra field in the Package KB.
Vendor based ICE Error count.
Name and shame....

[:)]