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]
________________________________
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Josh Rowe
Gesendet: Dienstag, 13. Mai 2008 19:26
An: WiX Users
Betreff: Re: [WiX-users] yep - back to being 100% frustrated
Agreed.
Software Engineering is many times about risk management. Many projects
leave understanding the deployment model of an application until just before
it ships, and then because MSI often isn't well understood and the product
wasn't written to work well with MSI people run into problems that cause the
ship date to fall back because of an installer issue.
If you reverse it, and do the install up front, this allows you to make
updating the installer a development responsibility and include the install
in your integration test suite. Doing an MSI integration test is trivially
easy: just spawn the MSIEXEC.EXE process passing your .msi file and
properties w/o a GUI in the way (msiexec /i x.msi /quiet ADDLOCAL=features
MYPROPERTY=1 MYOTHERPROPERTY=2 is what I'm using, I think). Now, if a
developer breaks the install, your automated tests should pick that up and
that developer can fix it long before the ship date.
Re. COM+ etc, I ran into exactly that problem and ended up writing a whole
CA system in MSI to deploy our 20+ COM+ applications at my last job. It
took weeks of effort to write deployment operations for our applications.
We started with .vbs and .zip files, but soon progressed to needing the full
functionality of MSI. It turns out that MSI really is quite simple, as long
as you work within what it does well from the beginning rather than trying
to back-port your existing application to be installed via MSI. We would
have chosen a different software model that would have cost a little more
coding time but a lot less deployment effort time if we had spent the time
to understand the deployment model up front.
The moral of the story is that deployment procedures really are part of the
source code for an application. They are also risky, so implement them
first to minimize risk.
jmr
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil
Sleightholm
Sent: Tuesday, May 13, 2008 12:51 PM
To: Scott Palmer; WiX Users
Subject: Re: [WiX-users] yep - back to being 100% frustrated
As this was my comment I thought I should respond.
>"I believe you should write the install then the code - if you can't
install it, don't code it."
>>That's simply not the way it works, and that isn't going to change. I get
where you are coming from though... the general installation layout of the
product does need to be >>understood sooner rather than later. The reason
that the installer isn't "done first" or in parallel with other development
is simple - everyone hates it. Getting anyone to do it >>is like pulling
teeth. Nobody on the team wants to be the "installer guy", for good reason.
(There is also the fact that it is intuitively backwards to write an
installer for >>something that doesn't exist yet.)
I like doing installs!
I know it is a bit flippant to say write the install first but in my
experience no one considers the install when choosing the latest and
greatest development code. If they did (and I feel Microsoft is to blame
here) they wouldn't touch a lot of the technologies. COM+ was never properly
supported for installs, moving up to date some of the WFP stuff is
incredibly completed to configure. SQL server it still not properly
scriptable without writing you own code.
I don't think it is intuitively backwards to write an installer first - my
analogy is - hydrogen powered cars might be a good idea but if you can't buy
hydrogen or aren't going to put the infrastructure in place there is no
point building them. I think the same is true of code, make sure you can
deploy it before you write any code. Together we can make it happen J
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
-------------------------------------------------------------------------
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
