• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

PowerShell namespace design?

  • Thread starter Alex K. Angelopoulos [MVP]
  • Start date
A

Alex K. Angelopoulos [MVP]

#1
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?
 

My Computer

A

Alex K. Angelopoulos [MVP]

#3
"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/archive/2006/08/31/PowerShell_Namespsaces.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
 

My Computer

K

Kenneth Hansen [MSFT]

#5
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/archive/2006/08/31/PowerShell_Namespsaces.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
>
 

My Computer