Bugs item #1752728, was opened at 2007-07-12 16:58 Message generated for change (Comment added) made by dr_barnowl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1752728&group_id=105970
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: heat Group: None Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Adrian Wilkins (dr_barnowl) Assigned to: Derek (derekc) Summary: COM DLL Harvester handles TypeLib versions > 9 badly Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Adrian Wilkins (dr_barnowl) Date: 2007-07-12 17:10 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1752728&group_id=105970 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ WiX-devs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-devs
