Make the impossible possible then talk about it.

Derek made a guest appearance tonight at the weekly WiX toolset coding night. It was fun having him around again.  We all caught up on the things that have happened in the last year or so. At the end of the night (about 1 AM), I dropped him off at his hotel downtown and drove back home. On my way home, I remembered a recent comment that was directed at Derek and I:

Derek and Rob, wouldn't it be better to first document all the current 3.0 features (SecureObj, Torch, Pyro, Setupbld etc) then [sic] adding support for a beta?

My simple answer is, "No." I think it is better to ensure that the WiX toolset supports as many of the available scenarios correctly as quickly possible. My primary goal is to make sure that setup developers can get their job done well and that the tools are not the obstacle blocking them.

That said, I recognize that documentation can greatly improve the speed at which developers can learn the tools. You will notice that with many of the new features going into the core toolset that there is a great deal more documentation than what has been provided in the past. We obviously have a lot of "documentation debt" that still needs filling in.

Ultimately though every user of the WiX toolset has access to the deepest level of documentation, the source code. As long as the WiX toolset supports the full set of features available from the Windows Installer then any developer can learn how to use them.

 

PS: No, I am not trying to argue that documentation is irrelevant. I'm just saying that with the finite number of resources that I have to put toward the project, making the impossible possible currently seems more valuable than going back and writing more documentation for that which is already possible.

 

posted @ Thursday, September 13, 2007 10:16 PM

Print

Comments on this entry:

# re: Make the impossible possible then talk about it.

Left by Mike Dimmick at 9/14/2007 2:52 AM

The worst offender IMO is the CustomAction element. It has 20 attributes, many of which only make sense when used in particular combinations (matching the main Custom Action Type that's generated). It would be better to document those combinations separately, but this can't be done by generating it from the XSD. However, nor can the XSD actually validate that the source is valid. I don't think it's possible to declare 'polymorphic' elements such as this in XML Schema.

It's rather too late to break this into multiple XxxCustomAction elements, though (although possible to support both). Can we support 17 different XxxCustomAction elements?

I guess it would be (action type in parens):

EmbeddedDllCustomAction (1)
InstalledDllCustomAction (17)
EmbeddedExeCustomAction (2)
InstalledExeCustomAction (18)
ErrorCustomAction (19)
PropertyExeCustomAction (50)
OtherExeCustomAction (34)
EmbeddedJScriptCustomAction (5)
InstalledJScriptCustomAction (21)
PropertyJScriptCustomAction (53)
ImmediateJScriptCustomAction (37)
ditto for VBScript (6, 22, 54, 38)
SetPropertyCustomAction (51)
SetDirectoryCustomAction (35)
and we don't support types 7, 23 or 39.

I'm not sure about the naming of 'PropertyExe', 'OtherExe', 'PropertyJScript', 'ImmediateJScript'. Even 'InstalledExe' isn't terribly clear that this is a file installed by the current package, but 'FileExe' was even worse. 'Embedded' is more descriptive than 'Binary' even though you'd still use a 'BinaryKey' to locate the file embedded in the installer through the 'Binary' element.

An additional problem is that compiler extensions could have extended the CustomAction schema, although I don't think this is very likely.

# re: Make the impossible possible then talk about it.

Left by Rob Mensching at 9/14/2007 3:28 AM

Mike, I agree with you. This is on my list of things that fall under the roadmap header of "improve the WiX language". It'll probably show up in a few more weeks. I haven't decided on the names of the elements so I'll start with your list and go from there.

PS: the Control element is pretty bad as well.

 re: Make the impossible possible then talk about it.

Left by Billyboy@theGates at 10/3/2007 7:47 PM

"the code is the documentation"

 re: Make the impossible possible then talk about it.

Left by Mike at 10/21/2007 12:58 PM

Yes, documentation is very important.
However, I find .chm and .doc files very bad at generating msi packages so I'd rather have the code first.

Your comment:



 (will not be displayed)


 
 
 
Please add 3 and 6 and type the answer here:
 

Live Comment Preview: