Thanks Rob. But the "code divination" that you speak of is not really
what I'm looking for. I'm not looking for some voodoo that will get me
out of doing my job, I'm just looking for a way to do it more
efficiently and effectively. The *actual* situation that I have is that
the files that make up the web application that I'm trying to create an
installer for change, at least slightly, from week-to-week. ASPX pages
get added, js files get removed, etc. The file system is a moving
target. I've discussed the maintenance of .wxs files with the
development team and the general consensus seems to be that having to
update/change a .wxs file to add or remove a "component" whenever a file
is added or removed from the codebase is not really feasible. The hope,
then, was that there might be some way, some tool that I could use, to
automatically generate a .wxs source file with all of the "components"
needed by simply pointing it at a given directory. I can setup my
automated build process to take the raw code directory and copy only the
files needed to a "staging" directory (remove all files with the
following extensions: .cs, .csproj, etc)...that directory then becomes a
mirror image of what I want the target machine to look like after having
run the installer.
I have no problem with creating a main .wxs source file with all of the
custom UI logic and stuff like that in it, but having to manually
maintain files for each and every single file that makes up an
application is tedious at best (more colorful ways of describing that
process come to mind as well).
The other major consideration here is the fact that I don't really have
a requirement to deploy to a large user base, nor is there a requirement
for component "upgrades" either. We're developing an installer to
simplify the process of internal deployment. Within the company that I
work, there is a completely separate organization that maintains our
server environments, and the deployment of applications to those
servers. The idea of simplifying that process for them by creating a
simple installer is very appealing to everyone. So, for our purposes, an
"upgrade" would really just be a matter of checking to see if the
application is already installed and if it is, uninstall it before
continuing with the current installation. There are a few custom actions
that I would want to perform as part of the process, but again, I can
write that into the installer source and handle that myself. I simply
want something that is capable of looking at a directory and generating
a source file with a component for each of the files and directory
structures in the given directory.
I hope that clears some things up. I also hope that makes what I'm
wanting/hoping/trying to do fairly easy. I just need some guidance as to
how to do that, whether it involves the use of heat.exe or something
else. If nothing else exists, fine...I'll write my own tool to do it. I
just wanted to at least ask the question because my scenario seemed to
me to be a common enough one that someone was bound to have faced this
challenge before me, and hoped that someone had already figured out a
solution for it.
Thanks.
______________________________________
// YEX //
________________________________
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Monday, May 21, 2007 1:16 PM
To: Yexley, Robert (LNG-CON); Scott Palmer
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Using heat.exe as part of an automated build
process
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]>
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
