Reg 'xxxxxxxx' is used in an unsupported way. ProgId - CLSID associations should be registered via the ProgId and Class tables.This entry may overwrite a value created through those tables.

From above, in what way fields of Registry Table is related to fields of ProgId and fields of Class tables. As i am new to packaging please give the detailed explanation.
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
You are seeing a warning and not an error, right?
You cannot resolve all ICE33 so please post the exact registry info you get the ICE for.
Answered 02/20/2008 by: AngelD
Red Belt

Please log in to comment
0
You can reolsve 90% of ICE33's the exception to that is Typelib related ICE33's which should be left in the Registry table, according to MS, and ignored.

To reolve them you need to create the relevent entrys in the ProgID, ClassID tables and remove the data from the Registry table. This should be done on the relevent component that the COM information relates too.

I would also like to add that using the "Search" feature on this forum will provide you a wealth of information on ICE33's and I thought I would save VBScab the trouble of typing the same thing in response to this post :)

P
Answered 02/20/2008 by: Inabus
Second Degree Green Belt

Please log in to comment
0
resolve all ICE33
I think the one you posted is a Warning and not an Error. This very warning is not going to affect the functionality of the application and in most cases can be ignored.
For the one you have posted is because the advertising information of ProgIDs and ClassIDs should be going through the respective tables. Also there is should be a Class ID associated with the ProgID (but this is not the case always). So in such a situation the tool captures this advertising information into the registry table.
I have tried resolving these ICE33 warnings in the past, by installing the source and then hunting the Windows Registry hives (regedit) and then manually typing them into the application MSI tables.
This is not generally recommended because:
1. You may end up making a mistake while entering the information in turn affecting the functionality
2. Its actually not worth the efforts (in terms of hours) as well. Due to these reasons its also an industry practice to ignore these errors unless you want to do it for knowledge.
I also think you may solve the ones which are generated if the advertising information going through both advertising as well as the Registry tables.

I will leave the discussion to the other experts if they can add something on this.

Cheers
Answered 02/20/2008 by: India_Repackaging
Blue Belt

Please log in to comment
0
ORIGINAL: Inabus
I thought I would save VBScab the trouble of typing the same thing in response to this post :)
LOL. As a bonus, the OP wouldn't have needed even to use 'Search' - there was a post TWO DAYS ago, entitled 'ICE33'. Maybe it was just hard to spot....
Answered 02/20/2008 by: VBScab
Red Belt

Please log in to comment
0
Good to see my joke was taken in good taste VBScab :p

P
Answered 02/20/2008 by: Inabus
Second Degree Green Belt

Please log in to comment
0
2. My package should be having zero errors and zero warnings..
To answer your statement from your other thread; as some warnings cannot be resolved I think that "requirement" will be hard to achieve.

Maybe if you understand what the ICE33 warning actually tries to say you don't have to "fix" them.
As some COM component registration information is not supported by the advertise related tables they will end up in the Registry table instead and my guessing is that is what you're seeing.
Answered 02/20/2008 by: AngelD
Red Belt

Please log in to comment
0
Actually, the ICE33 validation is pretty dumb. It just recognizes registry keys as possible candidates for the advertising tables, but it does not check if the keys can be put in there, or if they are already there. You can make the validation shut up by moving the keys to HKLM\Software\Classes, but that is only a reason to keep your clueless boss happy. I've seen people deleting these keys also [:@] The important thing to remember is to put the keys in the correct component, the component containing the file that is being referenced in the CLSID, Typelib etc.
Answered 02/28/2008 by: pgiesbergen
Orange Belt

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