I've recently downloaded v4 of Orca and noticed some Validation "differences" between the previous version.
If I validate my package with version 3 the following rows in the registry table return ICE33 warnings. Typelib should be registered via the Typelib table:









registry653
23
TypeLib\{420B2830-E718-11CF-893D-00A0C9054228}\1.0\FLAGS

registry651
89
TypeLib\{F49B86E6-CC92-4E5A-893A-DBA9D033AA8A}\1.0\FLAGS

registry648
1415
TypeLib\{A0B6F338-1223-456B-8617-C668D78D1DEE}\6.0\FLAGS

registry644
2021
TypeLib\{1BCD446E-7095-11D0-9C4E-00AA00BDD685}\1.0\FLAGS

With Version 4 I don't get any warnings.

Just wondered if anyone else had noticed this and whether it's because they are not valid in the first place
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
I would suggest that they have removed it because they have changed their position on whether the typelib table is a good thing to use.

From msdn: http://msdn.microsoft.com/en-us/library/aa372092(VS.85).aspx

--------------
Installation package authors are strongly advised against using the TypeLib table. Instead, they should register type libraries by using the Registry table. Reasons for avoiding self registration include:
  • If an installation using the TypeLib table fails and must be rolled back, the rollback may not restore the computer to the same state that existed prior to the rollback. Type libraries registered prior to rollback may not be registered after rollback.
-------------------

That paragraph is a fairly recent addition. It's certainly not in the Visual Studio 2005 MSDN docs.

Neil
Answered 06/10/2008 by: instedit
Orange Belt

Please log in to comment
0
If you open darice.cub in InstEd (or your other favourite msi editor), and look at
the _BadRegData table, you will see the formats for the reg keys that trigger ICE33's.

The TypeLib entries that trigger ICE33 have been removed in darice.cub for version 4.

Neil
Answered 06/10/2008 by: instedit
Orange Belt

Please log in to comment
0
Cheers Neil, Thanks for the info.
I've downloaded the latest version of insted and I'm very impressed.
Answered 06/10/2008 by: timmsie
Fourth Degree Brown Belt

Please log in to comment
0
Interesting - so until Wise / InstallShield captures stop populating the typelib table it's a manual job to get them back into the registry table.

Anyone know if the latest version (e.g. SP3 for WPS7) already covers this?

Wonder why this is now recommended best practice for the typelib table only and not class and progid tables. Getting into major geek territory here... [&:]
Answered 06/10/2008 by: MSIPackager
Third Degree Black Belt

Please log in to comment
0
To not let ex. Wise populate the Class, ProgId, TypeLib, Extension, Verb, MIME... tables you need to disable COM advertising. There is an option for that from the Tools -> Options -> Advertising tab (from memory).
If you are doing a capture set to retain registry as-is.

Yes, Microsoft do recommend not to use COM advertising but IMO that is only to minimize support calls or dissatisfaction from not-so-good-packages.
The vital part would be to make sure shared components to also share their GUIDs.

Mixing COM advertising and COM registry between application would be a not so good thing so I would stick with one of them.

Wise's Conflict Manager would to a lot of help to prevent broken components during install of one package were another uses the same resources.
Answered 06/10/2008 by: AngelD
Red Belt

Please log in to comment
0
Yep - fair shout. I think I'll stick to using the appropriate COM tables - typelib and all. Like you said - as long as your conflict management is in order then no worries.

Well spotted though timmsie - shame about your formatting... [;)]
Answered 06/10/2008 by: MSIPackager
Third Degree Black Belt

Please log in to comment
0
ORIGINAL: timmsie
If I validate my package with version 3 the following rows in the registry table return ICE33 warnings. Typelib should be registered via the Typelib table:

registry653
89
TypeLib\{420B2830-E718-11CF-893D-00A0C9054228}\1.0\FLAGS

registry651
1819
TypeLib\{F49B86E6-CC92-4E5A-893A-DBA9D033AA8A}\1.0\FLAGS

registry648
2829
TypeLib\{A0B6F338-1223-456B-8617-C668D78D1DEE}\6.0\FLAGS

registry644
3839
TypeLib\{1BCD446E-7095-11D0-9C4E-00AA00BDD685}\1.0\FLAGS

Just wondered if anyone else had noticed this and whether it's because they are not valid in the first place

If you do register the typelib from the TypeLib table the FLAGS entry will automatically be added during RegisterTypeLibraries action execution.

In that case you could just remove the FLAGS registry entries from the Registry table to remove that specific ICE33 warning.
Answered 06/10/2008 by: AngelD
Red Belt

Please log in to comment
0
As far as I know, MS are still happy for people to use general COM registration tables. The reason that the TypeLib table is a special case is because the registry entries created when using the typelib table are generated from an API (RegisterTypeLib). When a rollback occurs, UnRegisterTypeLib is called.

Because msi.dll is not in charge of the reg entry management (the older API's are) it can't guarantee that a reg value that preexisted the call to RegisterTypeLib is put back to it's previous state when UnRegisterTypeLib. Most likely UnRegisterTypeLib will just delete the reg entries.

Whereas when you use the registry table (or the Class, ProgId, etc tables) msi.dll manages the registry keys such that on rollback the reg state is the same as before the installation.

(Note that this is an educated guess, based on the hints from the documentation, and some knowledge of how COM works).

The question remains then, why don't MS just write their own MsiRegisterTypeLib API that combines whatever the RegisterTypeLib api does (parse the binary typelib and generate reg keys) with whatever the Registry table does to support rollback. It doesn't sound hard.

I mean, they already have the code for RegisterTypeLib. It's their own API.

Neil
Answered 06/10/2008 by: instedit
Orange Belt

Please log in to comment
0
ORIGINAL: AngelD
Wise's Conflict Manager would to a lot of help to prevent broken components during install of one package were another uses the same resources.

Should of course be during uninstall.
Answered 06/10/2008 by: AngelD
Red Belt

Please log in to comment
0
Hi Neil,

We had one user; can't recall if it was here at AppDeploy or at the Altiris forum, which stated that during rollback while he tested his package the old registry information was still there after a failing typelib registration.

Havn't checked any further on this.
Answered 06/10/2008 by: AngelD
Red Belt

Please log in to comment
0
Hi Kim,

He might be right. But I think the quote from msdn:


* If an installation using the TypeLib table fails and must be rolled back, the rollback may not restore the computer to the same state that existed prior to the rollback. Type libraries registered prior to rollback may not be registered after rollback.


would indicate that it is not expected that this will always be the case.

Neil
Answered 06/10/2008 by: instedit
Orange Belt

Please log in to comment
0
ORIGINAL: instedit
Whereas when you use the registry table (or the Class, ProgId, etc tables) msi.dll manages the registry keys such that on rollback the reg state is the same as before the installation.
Can I make a point quickly here? I was *just* on the point of querying your assertion here and then the light bulb went off: i.e. we are talking about ROLLBACK (in the even tof a failed install) and not UNINSTALLATION. Neither option caters for uninstallation in terms of restoring what was there before, of course which, in my opinion, is sub-optimal. To my mind, when you remove an app, it should restore the status quo. Of course, then you get into uninstalling apps in the reverse order to which they were installed...my brain hurts...
Answered 06/10/2008 by: VBScab
Red Belt

Please log in to comment
0
Spot on Kim. Whether you use TypeLib or Registry table, you are in the same leaky boat for uninstall.

Which I think is why their strong assertion to not use the TypeLib table is a bit over the top.

If the app can break things when things go right (correctly install, and uninstall) then
worrying about when things go wrong (rollback) seems a bit pointless.

(I had been intending to write a blog entry about this very issue. but all the info is here now [:)] )
Answered 06/10/2008 by: instedit
Orange Belt

Please log in to comment
0
Well, I for one am going to stick with the way I've done it for the last gazillion years, using the 'correct' tables and not the 'Registry' table. If it ain't broke...
Answered 06/10/2008 by: VBScab
Red Belt

Please log in to comment
0
Yeah, agree with you Ian.

Another point is that while not COM advertising you miss the extra entrypoints for triggering a self-check.
Answered 06/10/2008 by: AngelD
Red Belt

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