A summary of the Namespaces PowerShell defines and uses.
System.Management.Automation serves as the root namespace for PowerShell. The namespace contains the types a developer would use to implement a Cmdlet.
Sub-namespaces are defined for specific sections of the API that are used by specific types of developers.
System.Management.Automation.Host contains the types a developer would use to interact with the Host. The Host manages user interactions and creates the Runspace(s) in which scripts are executed.
System.Management.Automation.CmdletProvider contains the types a developer would use to implement a CmdletProvider.
System.Management.Automation.Runspaces contains the types a developer would use to create and manage a Runspace. A Runspace is the context in which a Cmdlet runs (the engine that actually manages a Cmdlet).
The Microsoft.PowerShell namespace
This namespace uses the System.Management.Automation APIs to implement the powershell.exe host and associated commands.
The .Commands namespace
Cmdlet classes (those types which implement Cmdlets) should be defined in a [YourNamespace].Commands namespace. This allows users of your API to distinguish those classes that implement Cmdlets (hence should not be called directly) from other portions of your API that should be called directly.
Note that CmdletProvider implementations (such as the filesystem CmdletProvider) are also defined in this namespace since these simply expose a new store to a set of common cmdlets.
In keeping with this convention there is a Microsoft.PowerShell.Commands namespace which contains the Cmdlets and CmdletProviders implemented by the PowerShell team.
The .Internal namespace
The .Internal namespace contains anything that should be treated as “internal” but must remain public for technical reasons. For example a class which only has internal members and constructors but is used as a base class for a public class. Members of this namespace should not be used directly.
Kenneth Hansen [MSFT]
Windows PowerShell/Aspen PM