Software Deployment

the validation suite doesnt really solve anything you are required to do that.

ICE 33 is an interesting one which requires alot of time to fix unless you are scripting it.

pgeiseman of the Wise forums offered a nice solution to ICE33 sometime ago.

It also has a huge bearing on how the component structures are made as to wether you need to fix them or not.

Wise tends to handle component grouping better than IS so its less of an issue with Wise than it is with IS.

Wether you should be fixing them depends on your own environment, if you can rebuild in minutes this why bother fixing ICE 33. its all relative to your environment really.

Are you referring to ICE33 errors or warnings?
There should be most of the time warning and not all of them is possible to solve.

Do a quick search on ICE33 and you'll find some past discussions regarding this.

In the last job I worked in we solved 99% of the 33 warnings we got, and the only ones we didnt resolve where the ones that caused errors on the DLL's during registration.

Comming from that environment I can say that resolving 33's is a must to ensure clean installs and uninstalls of the applications. This is especially true if your pushing out to thousands of machines and want to minimize or remove self repairs when people uninstall applications.

On the otherhand if you are rebuilding the machine every time it gets moved or errors appear then you could argue that it isnt worth putting the time into removing the 33's you get as any issues that leaving them produces will be ignored due to the rebuild regime that your company may have.

As someone previous stated, its entirly up to how your environment functions.

Regards,
Paul

Thanks for all your help guys... I'll search for the ICE33

If there is one or more you can't resolve try posting them here and we'll see what we can do for you.

5/13/2007

Hi,

Regarding your ICE33 issues. Like the previous person said... This isn't always an issue. With Vendor supplied MSI's, we usually leave them in the package. If you're recapturing an app, you should try to resolve these when possible.

The QA people from our organization will always fail an application if obvious ICE33's aren't resolved. ;)

When possible, you should use the CLSID and ProgID tables rather than the registry.

Where I used to work we even fixed vendor ICE errors via transforms. I dont think I have ever had a clean package yet that doesnt contain errors or warnings of some description. To be honest from what I have seen anyone can package but only a certain ammount of people can leverage the MSI technology correctly through properly authored MSI's.

To be fair though you do still have the "developer" effect where they badly compile their VB code and induce lower cases classes or some other stupid mistake.

Paul

Paul - fair point re developers - I've been trying to locate a great rant by RobMen about not fixing ICE33 errors and about repackagers not knowing enough about source code to do their job properly - he loves us really but he does have a tendency to rant... check his blog and if you find it let me know - I've just spilt red wine on the carpet so I'm a bit busy at the moment...
Regards,
Al

Alan,

I think you are referring to RobMen's Recommendation: Do not advertise COM information in MSI.

I have found that when building an MSI from "scratch" manually using Install Shield's "Create components for me using Best Practice" wizard (not capturing), hundreds - even thousands - of ICE33 warnings are generated, apparently exactly as if an installation was captured.

I don't know why IS wants to write the same data into both the registry table and the Class table, etc., but it does. So I have learned to ignore ICE33 warnings.

Regards,
William

Hi William,

If you do ignore ICE33 warnings then just make sure the entries in the advertise related tables and the registry table for the ActiveX/COM component is associated with the same component. If they arn't then uninstalling the application could break another using the same info which could trigger a never ending repair loop in worse case scenario.

Secondlaw - That is my deliemma. The QA people in my organisation want me to solve them if they come from capture. Vendor MSI is fine. I wud love to ignore them unless they are duplicates.

AngelD - thank you for the link

What it comes down to is information in the registry table that should be in the relevant tables in the MSI.

ProgID
Class
AppID
Typelib
Verb

The problem you get is that IS or Wise attempt to move them into the relevent tables during snapshot however fail when you get problem like lowercase class id's or mixed case appid's.

My first port of call would be to check that all the classID's referenced as warnings are actually in the class ID table with the information it points to, be that prog ID, app id or typelibs. Each 33 will be different but they, in the end, all point to something being in the registry that should ideally be in the relevant table.

If your having problems removing these warnings post a couple of example errors or warnings and we can attempt to walk you through moving them to the correct tables.

Paul

I don't know why IS wants to write the same data into both the registry table and the Class table, etc., but it does. So I have learned to ignore ICE33 warnings.

My guess is cos they dont know what they are doing.

IS is particularly bad when it comes to ICE33. My reasoning behind this is that IS dumps ALL clsid registry into a single component. All though I have to give them some credit cos at least this component is marked not to uninstall. I guess this is a slight positive.


[qoute] Secondlaw - That is my deliemma. The QA people in my organisation want me to solve them if they come from capture. Vendor MSI is fine. I wud love to ignore them unless they are duplicates.

As for this one maybe you should get them to explain to you why they should be fixed. Unless someone has a good reason for doing something there is no reason to do so.

If you really want to fix them though like i mentioned earlier pgeiseman of the wise forums had a nice solution to the problem.

The only reason I can think of to fix ICE33 warnings is if you are conflict managing your application suite. In my opinion, if you're not conflict managing, don't fix them!

I will try and run a little scenario passed you:

Developer A produces a package, removes all ICE33's and ensures all com information is deployed through the correct tables. He tests the package and finding no problems deploys it to the wider environment.

Developer B produces a package, doesn’t care about ICE33 and dumps all the com information in the registry. He tests the package, finds no problems and deploys that application.

In the live environment developer A's application was deployed months in advance of developer B's application. During an uninstall of developer B's application all registry information is removed pertaining to that application which, of course, includes all the registry information associated with that package.

This in turn causes the registry information required by developers A’s application to be removed, causing a self repair of that application.

Now lets face it, if the application is small this sort of thing isn’t an issue, but imagine if your application removes a component of an extremely large application that is badly authored? Can you imagine asking your user base to sit there while an application self repair for 30 minutes?

This does of course open up interesting questions about correctly authoring your features to ensure quick self repairs but at the end of the day avoiding self repairs in the first place should, in my view, take precedence.

Paul

if you are using conflict management and Wise this issue is not such a prolem.

As the DLL's themselves are reference counted.

The COM is associated to the same component effectively meaning the COM is also reference counted by virtue that its in the same component as the DLL which is counter.

If you are using installshield its also kind of not an issue as all Installshield COM is the same component and marked never to be uninstalled.

In each case Ice33 is sort of mitigated.

Where you have an issue is in Wise using Merge modules the COM is no longer protected and ICE33 is alive and kicking.