Hi
I just wanted to add that some of us had working installers before. In our
case this goes back to a fossil InstallShield v3 script based solution. The
only reason we're really forced to replace it, is because it contains 16bit
bootstrapper code, can you belive it ;-)
All the real deployment problems were already solved and working using this
antique technology. The latest version even supported Vista and respected
all (relevant) guidelines. So I can kind of prove it was by no means a
problem of our application, ever.
Granted there was no repair option, no change option, and just rudimentary
rollback in case of failure. But that was never a big problem for us in many
years.
Not even in my worst nightmare did I anticipate, what changing over to MSI
really meant....
_Mark
_____
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Josh Rowe
Gesendet: Mittwoch, 14. Mai 2008 17:30
An: wix-users@lists.sourceforge.net
Betreff: Re: [WiX-users] yep - back to being 100% frustrated
Actually, I'm not saying that at all. I'm just suggesting that these
problems should be solved up front because they are difficult to solve. I'm
also saying that by trying to solve deployment problems up front you may be
able to successfully influence the architecture of an application to not
include technologies that are ultimately difficult to use. If you wait to
solve these problems until the last possible second then you will not be
able to successfully influence the architecture of an "already-implemented",
"working" solution. The key point is that the deployment of a solution is
very much part of the solution itself, and if that happens to be the risky
part of a project then it should be tackled first. That's just good project
/ risk management.
If you want to influence an upstream "architect", you have to do so before
the software has solidified. If you believe strongly enough that MSI or
deployment in general is difficult, you should work on that part of the
project first with one goal to influence the design to be easily deployable.
When you don't have a choice, do what Christopher Painter says. I've had to
write CAs for MSI, too. Because of those experience, when given the choice
of writing CAs or changing the software to not require the CAs, I change the
software.
jmr
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Painter
Sent: Wednesday, May 14, 2008 10:06 AM
To: Neil Sleightholm; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] yep - back to being 100% frustrated
I think they are. Everytime you hear things like `solve the applicartion
problem`, `custom actions are an admission of failure`, `we won't implement
that feature`, `There are few setup experiences more stable than an
application that simply needs a bunch of files installed`, I believe that
very notion is being implied.
On one hand I understand why you'd say it, and in theory I agree with it.
But in practice it's not possible. The reality is even if you are lucky
enough to be in a shop where the developers/architects believe that their
design choices should be guided by integration ( read build/install )
implications, they rarely have the specialized domain knowledge to know what
those implications are because they usually never touched a build or an
install while they were cutting their programming teath. Setup is rarely
taught, it's not included in books, it's not included in certifications and
if you offer up a lecture at work or at a code camp you won't get anyone to
come. The reality is they are much more interested in discussing the
merits of the latest new thing. ( Agile, Scrum, ALT.NET, WCF, WPF,
SliverLight, DSL's are very popular topics at my local DNUG ... no one is
interested in MSI ).
So from my perspective, I try to influence upstream design decisions but
when it doesn't happen the way I'd like, I do what all good Marines do:
Adapt and Overcome.
Neil Sleightholm <[EMAIL PROTECTED]> wrote:
>>In any reasonably professional shop you can't just say "hey, MSI doesn't
>>support doing that, we just can't have that in our application!".
I don't think anyone was suggesting that but if you new it would need a
custom action, for example, you could either not do it that way or schedule
in writing one.
Neil
Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
