While browsing through the namespaces used by PowerShell, I noticed that
although PowerShell contains subsidiary namespaces, they seem to be a bit
disorganized. There's a root Microsoft.PowerShell namespace containing
"miscellaneous bits"; Microsoft.PowerShell.Commands, which contains commands
but also providers.

Is this structure intended, or just an artifact of the growth process?

This blog explains our namespaces and their usages. It was extensively
reviewed with the .NET team so while it may or may not be good - it was
certainly very thoughtful.

http://blogs.msdn.com/powershell/arc...mespsaces.aspx

--
Jeffrey Snover [MSFT]
Windows PowerShell/Aspen Architect
Microsoft Corporation
This posting is provided "AS IS" with no warranties, no confers rights.

"Jeffrey Snover [MSFT]" <jsnover@microsoft.com> wrote in message
news:eIf%23mcKzGHA.4648@TK2MSFTNGP04.phx.gbl...
> This blog explains our namespaces and their usages. It was extensively
> reviewed with the .NET team so while it may or may not be good - it was
> certainly very thoughtful.
>
> http://blogs.msdn.com/powershell/arc...mespsaces.aspx

OK. So, paraphrasing the area of my interest a bit and exploring a couple of
things NOT covered in the blog entry yet -

Microsoft uses Microsoft.PowerShell.Commands as the namespace for both
specific cmdlets and specific providers, because those are both about
commands: providers tend to extend the reach of commands directly.

A development group such as the PowerShell Community Extensions project
could then come along and to use a similar pattern so people familiar with
Microsoft's namespace would be able to understand the extensions namespace
structure. From what I see, the following look logical; any corrections?

(1) Assuming that the OEM/Project identification namespace is going to be
PsCx.PowerShell, the root namespace for PowerShell cmdlets and providers
would be PsCx.PowerShell.Commands.

(2) Using the very uniform current scheme for Microsoft's command names, a
development project would use Verb + Noun + "Command" for specific cmdlets.
For example, a New-Process cmdlet would have the fully qualified classname
PsCx.PowerShell.Commands.NewProcessCommand

(3) Analogously, new providers would use Storetype + "Provider"; for
example, an XML document provider would be
PsCx.PowerShell.Commands.XmlProvider

"Alex K. Angelopoulos [MVP]"

> A development group such as
> the PowerShell Community Extensions
> project could then come along and to use

Perhaps:

Framework Design Guidelines
Conventions, Idioms, and Patterns
for Reusable .NET Libraries
http://blogs.msdn.com/brada/archive/...11/450254.aspx

Yup, you've got it.
"Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
news:uWvegxRzGHA.4392@TK2MSFTNGP04.phx.gbl...
>
> "Jeffrey Snover [MSFT]" <jsnover@microsoft.com> wrote in message
> news:eIf%23mcKzGHA.4648@TK2MSFTNGP04.phx.gbl...
>> This blog explains our namespaces and their usages. It was extensively
>> reviewed with the .NET team so while it may or may not be good - it was
>> certainly very thoughtful.
>>
>> http://blogs.msdn.com/powershell/arc...mespsaces.aspx
>
> OK. So, paraphrasing the area of my interest a bit and exploring a couple
> of things NOT covered in the blog entry yet -
>
> Microsoft uses Microsoft.PowerShell.Commands as the namespace for both
> specific cmdlets and specific providers, because those are both about
> commands: providers tend to extend the reach of commands directly.
>
> A development group such as the PowerShell Community Extensions project
> could then come along and to use a similar pattern so people familiar with
> Microsoft's namespace would be able to understand the extensions namespace
> structure. From what I see, the following look logical; any corrections?
>
> (1) Assuming that the OEM/Project identification namespace is going to be
> PsCx.PowerShell, the root namespace for PowerShell cmdlets and providers
> would be PsCx.PowerShell.Commands.
>
> (2) Using the very uniform current scheme for Microsoft's command names, a
> development project would use Verb + Noun + "Command" for specific
> cmdlets. For example, a New-Process cmdlet would have the fully qualified
> classname
> PsCx.PowerShell.Commands.NewProcessCommand
>
> (3) Analogously, new providers would use Storetype + "Provider"; for
> example, an XML document provider would be
> PsCx.PowerShell.Commands.XmlProvider
>