SQL Use of MiniShells
The SQL team has been receiving a lot of bashing lately over some of the decisions they made integrating PowerShell into SQL 2008. I thought I would take a couple minutes to clarify a few things, eat some sin and talk about a constructive engagement model between the community and the feature teams implementing PowerShell cmdlets.
First let me declare my long standing admiration for the SQL team. Those superstars have consistently been one of the teams that really GOT what it meant to release software for production environments. They have a great quality culture and process and they have top-shelf leadership that reinforces this across the board. SQL has been the gold standard of great scripting because their GUIs produce scripts that you could harvest for reuse (yes it wasn't full coverage but they GOT IT years before anyone else). They are a great team - full stop.
The majority of the heartburn has come from SQL's use of MiniShells. A MiniShell is a non-extensible version of PowerShell with a set of baked in Cmdlets and providers. Some of my best community friends have pointed to SQL's use of MiniShells as evidence that they "don't get it". This is not correct. I told the SQL team about MiniShells and recommended that they use them because I thought they were a good fit for the sort of production-oriented value proposition they provide their customers. So direct your criticisms at me on this one.
First let's talk about MiniShells and why they exist. During the Vista reset, there was a great deal of anxiety about .NET versioning and general angst about instability arising from plugin models where code coming from the various sources run in the same process. Imagine the case where you load plugins from 10 different sources and then something goes wrong - who is responsible? Who do you call for support? MiniShells allow teams to address these issues by creating fixed execution environments that built in our labs and fully tested/verified before release. If you have a problem with a SQL PowerShell and call PSS, the first thing they are going to do is to have you try to reproduce the problem using the SQL MiniShell. (NOTE: In my experience, 9 out of 10 times that you have a problem with multiple plugins in a process comes from bad memory management - a problem largely [but not completely] managed out of existence by the CLR.)
The problem is not that SQL shipped a MiniShell but rather that there are SQL UX scenarios that use the MiniShell instead of a general purpose PowerShell. The SQL Management Studio GUI has context menus which launch their MiniShell. This is where we made a mistake. By definition, this is an escape out to an environment to explore and/or perform ad hoc operations. This environment does not benefit from the tight production promises that a MiniShell provides, in fact it is hampered by them. Because the MiniShell is a closed environment, you can't even manually add snap-ins. This is what sent people’s meters into the red - and understandably so.
Sadly it is too late to make this change for SQL 2008 but the SQL team will change this at their next opportunity. In the meantime, when you are at the MiniShell prompt, you can just launch regular PowerShell with a console file that contains whatever snapins you want to use (including the SQL snapins - they can be added to a PowerShell session). Clearly this is less than optimal but it is not onerous either. We are working with the SQL team on the PowerShel V2 designs to make sure that we can offer teams like SQL the safety/production quality they need while providing the customers the flexibility they want.
Let's take a minute and talk about the engagement model. I've encouraged the community to complain loudly when we screw up and aren't giving you want you want/need. No one benefits by you suffering in silence. In that regard, I can say that the MiniShell firestorm has been a big success. That said, for complaints to be actionable, they need to arrive in time to be acted upon. I'm sure that someone can point to a blog or email somewhere that pointed this out a long time ago but the reality is that it didn't pop as a problem until recently and now it is going to have to wait until the next cycle to get fixed. The good news is that the community feedback mechanism works, we just need to improve the timing.
One last note about tone. I've often joked that complaints were critical and politeness was desirable but optional (in other words, I'd rather get a rude complaint than polite silence). Let me take a moment to tweak that guidance a little. PowerShell is our passion and our day jobs and we'll endure almost anything to get the information we need to make this the best product ever. So that engagement model is totally applicable to the PowerShell team. That said, PowerShell is not the feature teams day jobs. In the case of the SQL team, it was a stretch goal pursued because of the passion of a small set of individuals (Michiel Wories in particular). The bottom line is that it is still critical to complain but when you complain about the feature team's support of PowerShell, just double check the tone and try make it constructive. Above all, let them know that you appreciate their efforts (just don’t get so wrapped up that you forget to include the complaint J)
Cheers!
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
