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