Scott,
Not everything that goes into the installer is COM and self registration.
Imagine you have a folder containing hundreds of html and gif files for your
product documentation. Now having a tool for automating the 'harvesting'
process such that every time you add few gifs to that folder, the tool keeps
the GUIDs for existing components and only creates new GUIDs for the gifs you
added. It seems to me like the solution is a catalog component, which it's not
that easy to implement (no component rules breaking).
Dacian
----- Original Message ----
From: Scott Palmer <[EMAIL PROTECTED]>
To: Rob Mensching <[EMAIL PROTECTED]>
Cc: "wix-users@lists.sourceforge.net" <wix-users@lists.sourceforge.net>
Sent: Tuesday, May 22, 2007 10:08:59 PM
Subject: Re: [WiX-users] Using heat.exe as part of an automated build process
The problem here is that Microsoft tools are already in the habit of automatic
code generation - and they all are designed to produce code for SELF
REGISTRATION. The process of self registration is effectively encouraged by
the development environment.
Now if the development process has to change, fine. But then we are forced to
throw out a great deal of the support in Visual Studio for building COM DLLs.
What replaces what was taken away? Heat is the closest thing I've found so far
and I fully understand that trying to extract the needed information from the
final code like it does can be problematic.
The point is it is a *huge* step backwards in productivity to go from SelfReg
DLLs to needing every developer trained in WiX so they can manually tweak the
installer every time they make a relevant change to their COM DLL, let alone
that they must now remember that this is even necessary. Other processes could
be put in place so the COM developer doesn't need to learn WiX but there will
still be added steps and opportunity for things to go wrong.
When you write: "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…"
If you were talking install, uninstall and rollback, then that's an excellent
argument for using SelfReg. Everything is nicely self-contained in the DLL and
no installer-related tool needs to get too complex.
Patching or anything else short of a complete uninstall followed by a
re-install is something I'm not interested in. It's asking for trouble
and simply not worth the effort. I've seen the writings discouraging
CustomActions on the grounds that they are just to hard to get right if you
need to account for all of those scenarios and I believe it.
Anyway... I'm just looking for a build process, including creating the
installer, that doesn't suck...
Something as simple as a tool that will take the .rgs files from my visual
studio projects and convert them to the appropriate WiX code might work. I
don't know yet. All I see is that the rules are changing and it's making
things difficult. "Code Devination" is something that was already there when I
used SelfReg... and it was working fine... but now we can't use it. The tools
we have to use don't do the job they used to, because they only support SelfReg.
We have the source for the ATL register and unregister code.. I wonder if a
tool like Heat couldn't just find all the .rgs resources in a DLL and derive
the WiX code from them? Perhaps I will write something like that to put in my
automated build.. that way the ATL COM wizard could almost be used without any
more manual tweaking. It turns out the wizards are buggy and screw up the .rgs
files too... putting different GUIDs in the IDL and .rgs files when the GUID
should have been matched, but that broke self registration as well, so the
developers know to fix that already.
Scott
On 5/21/07, Rob Mensching <[EMAIL PROTECTED]> wrote:
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.
-------------------------------------------------------------------------
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
____________________________________________________________________________________Ready
for the edge of your seat?
Check out tonight's top picks on Yahoo! TV.
http://tv.yahoo.com/-------------------------------------------------------------------------
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
