Software Deployment

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

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

Cheers Neil, Thanks for the info.
I've downloaded the latest version of insted and I'm very impressed.

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... [&:]

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.

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... [;)]

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.

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

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.

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.

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

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

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 [:)] )

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

Yeah, agree with you Ian.

Another point is that while not COM advertising you miss the extra entrypoints for triggering a self-check.