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]<mailto:[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
