#929 COM DLL Harvester handles TypeLib versions > 9 badly
For some inexplicable reason, MS decided to make COM TypeLib versions hex strings in registry keys and project reference strings.
System.Version.Version(string) will only parse integer version numbers. Passing a hex version string causes the following error conditions.
- Values greater than 9 are always handled wrongly
- Values containing characters [a-f] will cause System.Version to throw an exception, which is caught and the file handled as a different type.
- Values greater than 9 but not containing characters [a-f] result in the creation of TypeLib entries that look ok (classes nested inside, etc), but with incorrect version numbers (e.g. 17 instead of 23).
Light compiles decimal values correctly into hex values in TypeLib keys (verified by peeking with Orca).
Values above 9 are very common in VB6 projects, because the IDE conceals the details of constructing COM TypeLibs from the developer and will upversion them more than your typical C++ coder would choose to. I have custody of some libraries with TypeLib major version numbers beyond 0x2e, and the minor numbers affect many MS libraries like Visio 2002 (which has a minor number of 0xa).
Suggest:
Apply enclosed patch
Patch to improve TypeLib registry key handling for harvester
Logged In: YES
user_id=718275
Originator: YES
I've raised the priority of this because it can silently cause bad things to happen (wrong TypeLib version numbers)
e.g.
Typelib is installed at version 0xf - this occurs properly because heat will fall back to using plain registry values instead of constructing TypeLib elements.
Typelib is versioned up to version 0x10. Heat will boil this down to a TypeLib element with version 10 (decimal). New TypeLib is registered as version 0xa instead of 0xf (because light correctly compiles 10 to a key containing a hex "a"). TypeLib does not take precedence over old version. Things probably don't work.
Logged In: YES
user_id=991639
Originator: NO
Should be fixed in the next build.
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 15 days (the time period specified by
the administrator of this Tracker).