Very good points and I agree with you. Unfortunatly in my experience it's
almost always too late to do the upstream influencing and fixing. I've been
writing setup since 1996. In those 12 years I've held around a dozen
positions with various companies and completed dozens of additional projects on
the side. With only a couple exceptions, every project that I've been
invited to work on was very late in the project life cycle.
Sure, I'd love to sit in part time on a bunch of project startups and provide
guidance so that from build 1 they were on course for an easy deployment but
the reality is limiting my engagements to those parameters won't get my
mortgage paid. The `help, we need to deploy and we are screwed` customers
knock a lot harder and more often. It's in both of ours best interest to
service them with cost effective tools that enable me to adapt and overcome the
problems that shouldn't exist and yet do.
Josh Rowe <[EMAIL PROTECTED]> wrote:
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
-------------------------------------------------------------------------
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
