Re: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files
If there are utilities to bring a pure WiX 2 code base up to a pure WiX 3 code base then breaking compatibility is fine by me. We do not intend to mix the two. The utilities would eliminate costly manual conversion time and provide a quick way for the entire WiX 2 code library to be converted. So we could keep our existing WiX 2 library (just in case :)) then put upa parallel WiX 3 library and just make the switch wholesale and if WiX 3 floats in production then the WiX 2 library can be deprecated ... Note however we won't address the switch to WiX 3 until it becomes production ready. So on that note ... to help encourage the use of (and thus bug fixing of) WiX 3 to get it ready for production the conversion utilities need to convert from WiX 2 to WiX 3 and (to save our butts if WiX 3 doesn't get it done) convert from WiX 3 to WiX 2. You will need to weigh the cost of conversion versus backwards compatibility ... I'm clueless on just how would you automate a conversion. Dave WilliamsonClear Sky Software704.568.5544 sales704.554.6300 support704.943.0585 fax[EMAIL PROTECTED]www.clearskysoftware.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek CiceroneSent: Wednesday, July 26, 2006 6:50 PMTo: wix-users@lists.sourceforge.netSubject: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files WiX 3.0 currently has the ability to read library (.wixlib) files generated by the WiX 2.0 version of the toolset. However, weve recently identified several reasons why wed like to stop maintaining backwards-compatibility with the 2.0 format. The overall goal here is to make the changes necessary so that we never need to touch the wixobj or wixlib file formats ever again. All the proposed changes should make the contents of the wixobj and wixlib files so generic that all future improvements can be made by merely working with the existing concept of unreal tables instead of special 1-off xml and unreal columns. Drawbacks The one obvious drawback of this change is that customers using WiX 2.0 and 3.0 will not be able to share wixlibs from 2.0 to 3.0 as they may have done before. All 2.0 libraries must be converted to the 3.0 format (or re-built in 3.0) to work. For most groups, we anticipate that this will not be a problem since the move to 3.0 should only be done for a new product release and mixing versions of WiX in your build process is currently not advisable (its not a scenario we test very often). From 3.0 onward, however, we should be able to keep a consistent file format for wixobj/wixlib/wixout files. Advantages 1. Remove unreal columns from real tables Currently WiX internally uses a concept of unreal columns to associate additional information with standard MSI tables. For example, to associate a file path with a File row, WiX has a special Source column in the File table which is considered an unreal column. This basically means that wixobj and wixlib files carry the column but the final MSI file does not. The big danger with using this method of persisting additional information about standard tables is that should the MSI team ever decide to add additional columns to the tables, WiX will need to add hacks to ignore its unreal columns since all columns are addressed by their index (not the name of the column). In order to prepare for the possibility of the MSI team adding new columns to existing standard tables, wed like to remove the unreal column concept. This doesnt mean that metadata can no longer be associated with standard tables it just means it needs to be stored in a separate table like a WixFile table with a foreign key matching a File table entry. 2. Prefix wix-specific unreal tables with Wix There are currently several WiX-specific tables used between candle and light which do not actually appear in any MSI files. However, these tables do reside in the same namespace as normal tables that will be put in the MSI file. Some of these tables include: - FeatureGroup supports ComponentGroup authoring concepts - ComponentGroup support ComponentGroup authoring concept - Merge supports merge modules - Actions supports scheduling for standard and custom actions - SuppressAction supports suppression of actions - CustomTables supports custom tables without needing an extension - EnsureTables supports ensuring a table exists in an MSI file - RowData contains row information for CustomTables - UI supports UI elements The danger is that should MSI or any other group decide to use one of these names for a table in their setup package, a collision will occur and WiX will not be able to represent it properly. In order to prepare for this scenario, wed like to preface all WiX-specific table names with Wix similar to how MSI deals with collisions since MSI 2.0 but prefixing all their tables with Msi. This prefix will essentially become a namespace for WiX-specific tables
Re: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files
We already have a tool to convert from WiX 2.0 to WiX 3.0. Its called wixcop. I assume you were referring to converting the source code itself (not the wixlib files) since just having the libraries without source is a bit dangerous. We do not have a tool to convert from WiX 3.0 back down to 2.0. Once the time comes to ask everyone to switch from 2.0 to 3.0, the core tools should be extremely stable, and the decision to move to 3.0 should only be one way. It would be very painful to go from 2 - 3 and back to 2 since there are some concepts in 3.0 that will not translate back down to 2.0 sources (like not having short file names). The reason I assert that 3.0 core tools will be very stable by the time 3.0 is labeled stable is because Ive always set out to stabilize the core tools well ahead of the toolset as a whole. In fact, the WiX 2.0 custom actions still arent locked down whereas the core tools have been for almost a year. Thank you for this feedback, its good to see that no groups are intending to mix 2.0 and 3.0 in their organization so far. However, after much discussion over the issue, I think the hope is that WiX 3.0 will be the last time we touch the wixobj, wixlib, and wixout file formats. Were trying to make them generic enough that anything further can be supported via a new table instead of modifying the format itself. Derek From: Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Saturday, July 29, 2006 5:47 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files If there are utilities to bring a pure WiX 2 code base up to a pure WiX 3 code base then breaking compatibility is fine by me. We do not intend to mix the two. The utilities would eliminate costly manual conversion time and provide a quick way for the entire WiX 2 code library to be converted. So we could keep our existing WiX 2 library (just in case :)) then put upa parallel WiX 3 library and just make the switch wholesale and if WiX 3 floats in production then the WiX 2 library can be deprecated ... Note however we won't address the switch to WiX 3 until it becomes production ready. So on that note ... to help encourage the use of (and thus bug fixing of) WiX 3 to get it ready for production the conversion utilities need to convert from WiX 2 to WiX 3 and (to save our butts if WiX 3 doesn't get it done) convert from WiX 3 to WiX 2. You will need to weigh the cost of conversion versus backwards compatibility ... I'm clueless on just how would you automate a conversion. Dave Williamson Clear Sky Software 704.568.5544 sales 704.554.6300 support 704.943.0585 fax [EMAIL PROTECTED] www.clearskysoftware.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Wednesday, July 26, 2006 6:50 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files WiX 3.0 currently has the ability to read library (.wixlib) files generated by the WiX 2.0 version of the toolset. However, weve recently identified several reasons why wed like to stop maintaining backwards-compatibility with the 2.0 format. The overall goal here is to make the changes necessary so that we never need to touch the wixobj or wixlib file formats ever again. All the proposed changes should make the contents of the wixobj and wixlib files so generic that all future improvements can be made by merely working with the existing concept of unreal tables instead of special 1-off xml and unreal columns. Drawbacks The one obvious drawback of this change is that customers using WiX 2.0 and 3.0 will not be able to share wixlibs from 2.0 to 3.0 as they may have done before. All 2.0 libraries must be converted to the 3.0 format (or re-built in 3.0) to work. For most groups, we anticipate that this will not be a problem since the move to 3.0 should only be done for a new product release and mixing versions of WiX in your build process is currently not advisable (its not a scenario we test very often). From 3.0 onward, however, we should be able to keep a consistent file format for wixobj/wixlib/wixout files. Advantages 1. Remove unreal columns from real tables Currently WiX internally uses a concept of unreal columns to associate additional information with standard MSI tables. For example, to associate a file path with a File row, WiX has a special Source column in the File table which is considered an unreal column. This basically means that wixobj and wixlib files carry the column but the final MSI file does not. The big danger with using this method of persisting additional information about standard tables is that should the MSI team ever decide to add additional columns to the tables, WiX will need to add hacks to ignore its unreal columns since all columns are addressed by their index (not the name
Re: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files
It would take some work to rebuild our wixlibs, but we plan to rebuild them anyway when moving to 3.0 to take advantage of the embedded localization information. So, no problem here without wixlib backwards-compatibility. Regards, Martin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Thursday, July 27, 2006 7:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files WiX 3.0 currently has the ability to read library (.wixlib) files generated by the WiX 2.0 version of the toolset. However, weve recently identified several reasons why wed like to stop maintaining backwards-compatibility with the 2.0 format. The overall goal here is to make the changes necessary so that we never need to touch the wixobj or wixlib file formats ever again. All the proposed changes should make the contents of the wixobj and wixlib files so generic that all future improvements can be made by merely working with the existing concept of unreal tables instead of special 1-off xml and unreal columns. Drawbacks The one obvious drawback of this change is that customers using WiX 2.0 and 3.0 will not be able to share wixlibs from 2.0 to 3.0 as they may have done before. All 2.0 libraries must be converted to the 3.0 format (or re-built in 3.0) to work. For most groups, we anticipate that this will not be a problem since the move to 3.0 should only be done for a new product release and mixing versions of WiX in your build process is currently not advisable (its not a scenario we test very often). From 3.0 onward, however, we should be able to keep a consistent file format for wixobj/wixlib/wixout files. Advantages 1. Remove unreal columns from real tables Currently WiX internally uses a concept of unreal columns to associate additional information with standard MSI tables. For example, to associate a file path with a File row, WiX has a special Source column in the File table which is considered an unreal column. This basically means that wixobj and wixlib files carry the column but the final MSI file does not. The big danger with using this method of persisting additional information about standard tables is that should the MSI team ever decide to add additional columns to the tables, WiX will need to add hacks to ignore its unreal columns since all columns are addressed by their index (not the name of the column). In order to prepare for the possibility of the MSI team adding new columns to existing standard tables, wed like to remove the unreal column concept. This doesnt mean that metadata can no longer be associated with standard tables it just means it needs to be stored in a separate table like a WixFile table with a foreign key matching a File table entry. 2. Prefix wix-specific unreal tables with Wix There are currently several WiX-specific tables used between candle and light which do not actually appear in any MSI files. However, these tables do reside in the same namespace as normal tables that will be put in the MSI file. Some of these tables include: - FeatureGroup supports ComponentGroup authoring concepts - ComponentGroup support ComponentGroup authoring concept - Merge supports merge modules - Actions supports scheduling for standard and custom actions - SuppressAction supports suppression of actions - CustomTables supports custom tables without needing an extension - EnsureTables supports ensuring a table exists in an MSI file - RowData contains row information for CustomTables - UI supports UI elements The danger is that should MSI or any other group decide to use one of these names for a table in their setup package, a collision will occur and WiX will not be able to represent it properly. In order to prepare for this scenario, wed like to preface all WiX-specific table names with Wix similar to how MSI deals with collisions since MSI 2.0 but prefixing all their tables with Msi. This prefix will essentially become a namespace for WiX-specific tables and should not collide with other products. This change will not affect custom action tables like IIsWebSite, SecureObj, XmlFile, etc These must now stay consistent since they ship in MSI files to avoid breaking scenarios in which customers already use these tables. 3. Remove custom xml in wixobj wixlib files Currently WiX passes special information between the compiler and linker in the form of special xml in the wixobj and wixlib files. Over time, we came to recognize that usage of this custom xml was not very extensible and cause a lot of problems whenever a change needed to be made because it basically invalidated the entire wixobj and wixlib file formats. Going forward, we have recognized that the best way to avoid this problem is to persist information between the compiler and linker using unreal tables. This is why WiX 3.0 recently stopped using complexReference elements in
