I've recently been very upset with the attitude from Redmond ( Ala we will write the patterns thank you very much.... custom actions are evil and we aren't going to help you roll your own patterns despite the fact that we are sitting around doing nothing to standardize these patterns for you. I'm sorry, but there are crucial stories missing from Windows Installer and I don't see them doing anything about it to update the technology.
No NGEN pattern
Broken GAC MSIL patterns ( commit race problems with trying to start services or invoke webservices with GAC dependencies )
No native XML patterns
No IIS patterns
No managed framework classes
No P/Invoke wrappers
COM interfaces that don't properly generate primary interop assemblies
No native support for managed code custom actions
No support for invoking webservices
No database support
Poor INI AppSearch support
Lack of Account Management capabilities
Very poor ACL support ( LockPermissions is broken )
No driver installation support
Very little native support for package serialization stories
Aging UI story
Very little support in GPO for setup.exe driven installs ( becoming more and more important as installs have to serialize prerequistes, have external UI handlers and generally perform .NET configuration actions outside of MSI because Windows Installer just can't hack it.)
The list goes on and on.....
Now I generally like MSI, after all I do use it every day. However, C++/data driven abstraction is how we were designing systems 10+ years ago... The world has moved on to better designs. MSI does many things right, but there are also many things that it doesn't even try to do. Worse, they seem to think the solution is to tell us not to try to do it also.
Although I've been using Windows Installer for years, I'm starting to wonder what's next and how long I'll be using this aging SDK.
2 comments:
I don't think we will be using it much longer. 85% of my deployment development time is spent on CAs and not MSI tables. What does MSI buy me anymore? Automatically rolling back files if a CA files? Automatically in Add Remove Programs?
There has been a lot of focus on PowerShell (We have more deployment flexibility then many vendors because we deploy enterprise software so the servers we deploy to are dedicated to our software.) With PowerShell and things like Remote Runspaces (http://www.hanselman.com/blog/ScriptBlockAndRunspaceRemotingInPowerShell.aspx) you can perform an install across several servers from one central server. This isn't a simple PUSH pattern either. The central server actively communicates with the target server and the target server responds back. You could have all the other servers rollback if one server failed or any other type of logic.
Sure, this stuff is pretty "out there" but just as you, our frustration with MSI has lead us to drastic measures. MSI just doesn't buy us anything anymore.
Some of the things we do in CAs that MSI AND IS doesn’t do or does so badly that we don’t use the support:
DCOM configuration
SQL server script execution
Adding Windows Users to groups
XML document manipulation
.config file management like adding probing paths, assembly redirects, etc
IIS management
Launching exes and capturing the output
Windows Account password validation
And a ton of other stuff.
MSI just doesn't help us with any of these things.
It is hard to suggest others to use MSI when it has one of the worst learning curves ever. What does it buy you to take the time to learn it? I have taken the time ( 6+ years developing with it) and if feels like a dead end to me. We can’t use managed code, we can’t write standard unit tests, and only a few people know it. How can it ever fit into a modern software development lifecycle?
Peter,
One of the overall benefits windows installer offers is one many people dont even have a view on.
People often look at windows installer as a single application deployment mechanism. However it is much more than that. It's core design is around 100's or 1000's of applications playing nicely together throughout an organisation. I only know of one company in the world which levarages this capability. Does this mean other vendors are not aware of it ?
No other deployment solutions offer this on the market today however virtual technologies are coming to the forefront more regularly which offer similar conflict management type solutions using entirely different methodology.
Post a Comment