> Then those generated cmdlets must be instances of .NET classes, because by definition that's what cmdlets are Nope. The problem is that you searched for conf

> Then those generated cmdlets must be instances of .NET classes, because by definition that's what cmdlets are Nope. The problem is that you searched for confirmation that cmdlets was "just" .NET classes (I really don't get why that is important), and then you dive into documentation for C# programmers and point out how the documentation for C# programmers is telling the C# programmer that if he wants to create a cmdlet he can do it with a C# class. D-oh! When I point to the PowerShell specification and demonstrates how it does not claim that cmdlets are .NET classes you ignore it. I point out how it enumerates the 3 different ways to make cmdlet modules: Binary, script and manifest, of which only the binary module variety implement cmdlets as classes. You could equally well claim that Web Services are just MVC Controllers, because in the documentation for MVC I can find out how to implement web services using MVC controllers. > ... and they exist within the .NET runtime, which is the relevant issue Why? If the .NET runtime has become sediment to the point where the OS is always distributed with the runtime, where important OS functions (like troubleshooting) is implemented using the runtime, where remote administration is based on the runtime, at what point do you accept the runtime as part of the OS? .NET IS part of Windows now, has been since Windows 7 SP1 (IIRC). Troubleshooting packs, guides etc. are written using PowerShell. When your network gets the hiccups, and Windows proactively offers to troubleshoot the network connection, it is PowerShell that is running underneath. The new PackageManager is PowerShell based. > Thank you, however, for providing yet another demonstration of how PowerShell advocates consistently resort to handwaving, obfuscation, and false claims in order to try to pretend PowerShell is functionally different than it actually is. No need for snide remarks. I stand by all of my claims. It is you who selectively quote C# programmers documentation out of context. All you have proven is that if a C# programmer wants to create a cmdlet using C#, he must implement it using a class.