|
We already have a tool to convert from WiX
2.0 to WiX 3.0. It’s 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 I’ve
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 aren’t locked down
whereas the core tools have been for almost a year. Thank you for this feedback, it’s
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. We’re 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] 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 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
