A long time ago, Rob Mensching had a blog post promoting a 100% declarative installation model and lamenting custom actions as an admission of failure. He then went on to enumerate three general reasons or the need of custom actions. One of them was:
The setup developer wrote a custom action to configure some platform because the platform technology didn't provide installation primitives for itself. This one is just sad and, unfortunately, happens more often than not.100% declarative sounds great, but you back yourself into the "640K is enough for anyone" corner because one day a the "box" won't be big enough and the platform will be too slow to catch up.
Don't believe me? Take a look at all the times Windows Installer as "failed" us by not providing us a declarative way of doing something?
Read/Write XML
Read INI other then the Windows Folder
Persisting properties across transactions ( "Remember Property" pattern )
Closing Windows and Killing Processes
Executing SQL Scripts
Configuring IIS
Configuring Reporting Services Reports
Recursively deleting directories
Configuring firewall rules
Configuring Visual Studio AddIns
Granting Users Logon as Service Right
Creating Users and Groups
Configuring COM Plus
DIFx
Game Explorer
MSMQ
NativeImage Generation ( Ngen )
PowerShell Snapins
The list goes on and on. Now I know, "But Chris, Metro Apps aren't intended to do those things." OK, but do you *REALLY* know what Metro apps need down the road for? When the requirements change will AppX be updated fast enough to support the new requirements?
I know Windows Installer has never been able to prove itself in this area. So the purists can preach that custom actions are a failure and I'll admit in many cases ( reinventing the wheel and writing sloppy CA's ) they are but in many cases they are the only way to get the job done.
So will AppX work holding the line the way it is? I think Yoda answered it best:
Difficult to see. Always in motion is the future.
No comments:
Post a Comment