0. Okay, so you're looking for "simplistic code divination". <smile/>
1. I've never met a dev team that when presented with the option of doing more
work accepted (unless it was some cool graphics work or something). <smile/>
Distributed development rarely happens because each developer says, "Ooh, I
want to maintain the system how my files get installed" (although some do). It
usually happens because someone that can see the big picture says, "Our
processes and product would be better if we distributed the labor across all of
our developers so that the people with the knowledge of how things work are
responsible for making them work." I often compare this to the build process.
Are the individual developers responsible for adding their new source files to
the build system? In this day and age, the answer is almost always yes. I
don't know why adding new files to the product is different.
Note, I'm not being critical. I'm just trying to push conventional wisdom a
little bit so that people at least entertain the idea that setup development
should be distributed like all the rest of the development. The fact that the
WiX toolset integrates into a build process makes this possible where
(historically) other setup authoring tools tended to centralize the work.
2. Because you have such a controlled environment it may be possible to
generate the portions of setup as you desire. Your strict rule of uninstalling
before installing the next version makes this possible *as long as* you never
have shared resources. If you share resources, you again have to worry about
automagically generating the shared GUIDs.
3. Heat.exe is not the tool you're looking for (although it looks a lot like
the one you need) because the WiX toolset is not tailored for any particular
environment. Because the WiX toolset is intended to be used by anyone that
needs to build Windows Installer packages we keep the tools following the
widest array of best practices possible.
In the distant past there was an "autogenerate" feature (like the one you
describe) as part of the WiX toolset. A team used that tool to ship their
product. When it came time to patch the product they were screwed because they
had to install into far less controlled environments than the one you described
and had to take into account some shared libraries. They were livid with me
and the WiX toolset for not pointing them in the right direction. Since then,
I've shied away from adding features that could silently hose a developer.
4. That said, I have a couple research projects going on to try to aid "code
divination" tools.
5. So, bottom line, as long as you can control your environment then you can
probably get away with a very simplistic "code divination" tool and since the
WiX toolset operates in a great many uncontrolled environments we have not yet
figured out how to write a "code divination" tool that works correctly in all
cases.
PS: Feel free to keep checking back here or my blog,
http://robmensching.com/blog. If any of the code divination research bears
fruit, I'm quite certain I'll be blogging about it. <smile/>
From: Yexley, Robert (LNG-CON) [mailto:[EMAIL PROTECTED]
Sent: Monday, May 21, 2007 12:21 PM
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
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]<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
