Hi all > If you reverse it, and do the install up front [...] I agree that things like KnownFolders and related security implications should be considered early in the development process. But this should be a high-level architectural topic, well above the trenches of writing an actual installer. In most respects however, the IT incarnation of the "chicken or the egg" dilemma is *moot*! 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!". Not deploying a default configuration file, just because MSI can't do it, is not an option for most if not all professional developers. How does writing the installer up front help here?
That's just one example. See the long list of problems I already posted in this thread. Most of these problems just *have* to be solved, whether up front or later doesn't matter. _m ________________________________ 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
