|
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 up a 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, we’ve recently identified several reasons why we’d 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 (it’s 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, we’d
like to remove the unreal column concept. This doesn’t 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, we’d 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 the wixobj files and instead switching to
unreal “WixComplexReference” tables. The tables basically allow us to add
columns as necessary without breaking backwards-compatibly with previous
versions of the wix toolset. This change – removing custom xml from the
wixobj and wixlib files – can be made without sacrificing
backwards-compatibility with WiX 2.0 wixlib files. However, I’ve called it out
here because this change is what prompted us to begin looking at breaking
backwards-compatibility. Basically, we found that due to the way certain
tables are handled (like the File) table, we had to go to extremes in the
codebase in order to maintain compatibility. Thanks, Derek |
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
