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
