1. Yes. You are correct. Many tools in Visual Studio still encourage self
registration. It has been a long hard fight (6 years or so) and I’m just
starting to get people over there that understand what a horrible example they
are setting. Some of them have asked, “Why is deployment so hard” and I point
at the things they’ve done to encourage SelfReg (ATL built in and Installer
classes). Believe it or not, SelfReg is a key component of the pain that
was/is DLL Hell.
2. I agree that other processes should be put in place to move completely away
from SelfReg and towards declarative statements. I would like to point out
though that if Visual Studio did not automatically generate the registry code
for you to write all of your keys to the registry that you’d probably be
complaining about that amount of work. It takes far less effort to declare
your COM registration in the WiX toolset (sometimes only one Class element)
than code to write the dozen or so registry keys.
3. Actually your comment about SelfReg being self-contained is actually the
root of the issue. The SelfReg code can’t see enough of the big picture to do
the right things in all cases. For example, let’s say you and I share a DLL
that is SelfReg’d. User installs your app and my app (order doesn’t matter).
User decides she doesn’t like my app so she uninstalls my app. My app calls
off to the SelfReg DLL to uninstall and suddenly your app doesn’t work anymore.
That pretty much sucks for the user, eh?
4. I’m glad that your application is simple enough to be completely happy with
the major upgrade functionality provided by the Windows Installer. That
certainly the easiest way to do things. However even that simplicity does not
solve the problem I pointed out in the scenario in #3 above.
5. “All I see is that the rules are changing and it's making things
difficult.” The rules are not changing. These rules have been in place for
almost a decade now and the rules really applied before that.. there just
weren’t many people that were aware of them. Because many people weren’t aware
of them bad things happened, DLL Hell being the most famous.
6. As I’ve noted in other threads, if you have a controlled environment and
all of your stuff isolated from the rest of the world and you don’t do any
sharing in your application then you can get away with pretty simple “code
divination” rules. There are admittedly not good tools in the WiX toolset
(yet) to do this simple code divination (because it doesn’t work at all in many
cases).
From: Scott Palmer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 22, 2007 1:09 PM
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
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]<mailto:[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
