I once looked into using Powershell as a foundation for an application that was to be very heavily powered by scripts underneath. It seemed like an idea with a lot of promise—most of the libraries it was to work with were written in .NET, the users were comfortable with scripting, and it would have been easy to expose GUI components in a scriptable way (think VBA for Office)—however, actually getting the thing deployed would have been a totally different manner.
Most firms lock down end-user machines. This makes for a more secure and easier to manage network, but it makes deploying an application an absolute nightmare when an application requires a non-trivial installer and administrative privileges to use.
And that brings me to the title of this post. Powershell deployment options are awful. Considering that Powershell is written largely (exclusively?) in .NET, it’s unbelievable that an installer has to be run, files need to be installed in system directories, and registry keys need to be written. About 99% of what it does can be done in pure .NET, and any app written in pure .NET can be copied to a directory and run as long as its dependencies are in the same directory or in the GAC. Life would have been much simpler for me if I could just include the Powershell .NET assemblies, deploy them with my application, and run Powershell scripts.
And then let’s say I do end up being able to deploy PowerShell properly, with all its funky registry keys and whatever else that installer does; what am I supposed to do with any PSSnapIns that I’m dependent on?
Somewhere on the Microsoft campus, there needs to be a giant poster called “Lessons Learned”. It should include at least the following bullet points:
- No Clippy. Cartoons don’t help people get work done—functional software does.
- People like XCOPY deploy—installers are obnoxious.
Well, they removed Clippy from Office 2007. Right now, .NET apps are so simple to deploy it’s criminal. So what’s the deal with Powershell? —DKT