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.)