WiX is intended to be used in an automated build system. It fits in extremely
well with every automated build process that I've been introduced to.
What you appear to be looking for is an "automated code generation" process.
Code generation is a completely different problem than building. Code
generation is about divining what a developer is thinking (or at least should
be thinking) and writing the code for him or her. The WiX toolset does not
include any good "automated code generation" tools.
There are tools (namely heat.exe, and dark.exe if you start with an MSI) to
help developers capture large amounts of data and translate that into .wxs
code. But those tools are designed to be guided by a developer, not run
blindly in an automated build process. Of course, the results of the tools can
be checked into source control and then operated on in an automated build
system.
Note that writing a "automated code generation process" requires significant
amount of domain specific knowledge. I had a conversation just this last week
with a developer from a company where significant amounts of IDL and VB code is
generated by the build process. In that company "analysts" can only write code
into some well known named functions and the rest of the structure was provided
for them. Because the system was so structured (and strict) he was able to
automatically generate the .wxs code in much the same way the IDL and VB code
was generated (for example he was already handling breaking interface changes
and there is no resource sharing).
Another very large company has strict development guidelines and provides their
developers with a complete template of .wxs code that adheres to those
guidelines. If the developers need to stray from the company development
guidelines then they can tweak/extend the template .wxs code as necessary.
However, the generated template code no longer applies. That company likes the
WiX toolset because it provides both a solid starting point and the flexibility
when needed.
I have yet to see an automated code generation tool that can just point at any
application of any complexity and go, "Oh, that's a FizzlyBear and it needs to
be installed, uninstalled, upgraded, patched, and handle rollback like this.
Oh, and it needs to be per-user/per-machine and store state in this location
and... and... and..."
Today the WiX toolset provides a solid foundation for your automated build
system. We're still dabbling in tools to help make it easier to work with the
.wxs code but "Code Divination" is still a skill I haven't mastered at Hogwarts
yet.
From: Yexley, Robert (LNG-CON) [mailto:[EMAIL PROTECTED]
Sent: Monday, May 21, 2007 6:19 AM
To: Rob Mensching; Scott Palmer
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Using heat.exe as part of an automated build process
Is WiX designed to be used in an automated build process? If so, is there any
guidance anywhere on how to do so? I need an installer, and I need it to be
generated as part of an automated build process. The code based that it needs
to be generated from is a moving target...changes on a ~weekly basis. If WiX
isn't what I'm looking for, that's fine, I can move on. I just need to know
that.
______________________________________
// YEX //
________________________________
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Friday, May 18, 2007 10:23 PM
To: Scott Palmer; Yexley, Robert (LNG-CON)
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Using heat.exe as part of an automated build process
Heat isn't designed to be used in an automated build process.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Palmer
Sent: Friday, May 18, 2007 7:10 PM
To: Yexley, Robert (LNG-CON)
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Using heat.exe as part of an automated build process
Not exactly. If you use Heat on a COM DLL, Heat inserts "PUT-GUID-HERE" for
the GUID so you can do a search/replace as part of the automated build to keep
the GUID correct and always the same for that component.
Other issues are with the directory structure that Heat uses and the fact that
it's output doesn't compile anyway.
It seems Heat isn't ready for real use yet.. to be expected I guess.
Scott
On 5/18/07, Yexley, Robert (LNG-CON) <[EMAIL PROTECTED]<mailto:[EMAIL
PROTECTED]>> wrote:
I'm still learning the ins and outs of WiX. I'm working on trying to integrate
the generation of an MSI into our automated build process, and was wondering
about the possibility of using heat.ext to harvest the files needed for the
features and components for the MSI. I've read a few archived messages from the
list that suggested that doing something like this could potentially be
problematic, and isn't recommended, but if I understand correctly the reasons
why, I'm not sure it would really cause us a problem for what we're wanting to
accomplish. So, I'd like to try to confirm whether or not I understand what the
issue is with using heat, describe why I don't think its an issue for us, and
it'd be great if someone could confirm whether my thinking is correct or not.
So, if I understand correctly, the issue with using heat.exe to generate source
files for me as part of an automated build process is that for each build, the
GUID for each component would be different on each build, which causes problems
for the installer if you want it to be able to "upgrade" a product
installation. Is that right?
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
