After being a part of a few email threads and discussions about Citrix not following the traditional name-verb cmdlet naming scheme I thought I would make a post with my take on that.
Basically, Citrix joined companies like Microsoft, VMware and Quest and is also trying to PowerShell-enable all of their products. However, they chose to not follow the standard naming scheme and went with a few of their own.
The ones for Provisioning Server are just bad: They user verb instead of a noun, prefix instead of a verb, and noun instead of a parameter.
So instead of: Add-Device – they have: Mcli-Add Device.
XenServer ones are slightly better (verb is where it is supposed to be) but nouns get colons and dots – something no other company in the world is using:
Get-XenServer:VM.NameLabel
I think I understand why XenServer guys are designing their cmdlets that way – they simply try to workaround the namespaces issue which PowerShell has (see my blog post about that and vote for the bug on the connect site)
Basically, they want to make sure that their cmdlets don’t produce naming conflicts if administrators also have VMware and Microsoft cmdlets on the same box.
We had the same issue with our AD cmdlets and are using QAD prefix for every noun: e.g. Get-QADUser.
So I totally agree that the issue exists but I urge Citrix and other companies to not try to workaround it in a way so inconsistent with what everyone else is doing. We will simply do a very bad service to administrators who have to manage more that one system. Consistency is key to the success of PowerShell and I hope we can maintain that.
My suggestions:
To Microsoft: As vendors start adopting PowerShell we will be getting increasingly more issues like that, so please:
- Consider enforcing naming standards in PowerShell and Visual Studio templates or at least (if the fear of losing backwards compatibility is strong) make sure that compilation and snapin registration produce warnings if non-standard cmdlet names are used.
- Please provide a viable way of handling cmdlet naming conflicts. Administrators should be able to easily avoid these and get predictable results.
To Citrix:
- Please get back to the standard Verb-Noun (or Verb-PrefixNoun) notation.
- Consider giving your snapins short names so your aministrators could use:
XenServer\Get-VM(or justGet-VMif there’s no conflict) rather thanGet-XenServer:VM.
Tags: Citrix, PowerShell, cmdlets
Subscribe by email
Dmitry's Blog: Cloud, PowerShell and beyond 
2nded. MS needs to take the lead on this one. In the past MS has said that this is a very hard problem with no good solution, but if they don’t solve it PowerShell could become a victim of its own success.
Thanks for your comments, Dmitry. As you note, the natural names for the Citrix XenServer cmdlets would clash with VMware’s in many cases. For this reason, we’ve added a prefix to each noun.
In addition, we added a command to create shorter aliases, for those who don’t have the namespace problem. Calling “Initialize-XenServer:Aliases Start” will make it possible to use names such as “Start-VM” and “Get-VM” instead, just as you would like.
I have a blog post explaining Initialize-XenServer:Aliases (and many other things about the snap-in) at
http://community.citrix.com/blogs/citrite/ewanm/2008/10/08/XenServerPSSnapin+Demo+-+Chained+VM+Starts
We’re obviously not alone in looking to Microsoft for a lead on this. The guidance seems clear that you should not mess around with the verb, so we chose to put our namespace in the noun instead. Without proper guidance from Microsoft, inconsistency across the community is inevitable.
You mean “Consider enforcing naming standards in” PowerShell (not Visual Studio) right?
I must admit that sometimes I wonder why they didn’t enforce their standard list on the Cmdlet parameter by making it a strict enum instead of a string, but there you go.
Hi Dmitry,
this is never ending discussion and my personal opinion is that it will be (and IMHO should be) before Microsoft kicks in and updates naming convention for PowerShell…
We had pretty lengty discussion here about it: http://martinzugec.blogspot.com/2009/03/smart-function-names-in-powershell.html
I would like to blog about it today, because without namespaces my life would be much more complicated. I use :- at the moment, however if there would be any industry standard (like \-), I would be more than happy to follow it 😦
Martin
Ewan,
I totally get that you are trying to avoid naming collision and when you have time please vote for the namespace feature request for PowerShell at connect: https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=301052&SiteID=99 (plus probably add your comments to the request, etc.)
However, I am not sure why would not you just use: XenServer\Get-VM instead (if you make XenServer your PSSnapin name) – this will provide the collision resolution in a PowerShell way, right?
Dmitry
Joel,
Yes, sorry for the typo. Was thinking 2 things at the same time. They can actually enforce/warn in both places – PowerShell itself and Visual Studio templates – would provide a bigger outreach…
Dmitry
Martin,
Let’s keep pushing for namespaces: https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=301052&SiteID=99
The \ notation is actually a PSSnapin resolution and thus a full name which should work for cmdlets already. Did not try this for PowerShell v2 modules – hopefully will work there too.
Dmitry
Hi Dmitry,
no worries, already voted few times. Today I will post link to your feature request at my blog also (power of community ;))…
I use prefixes for long time already at big customers with different skills, so I can tell you that they work really nicely without any problems.
Two problems I encountered though are:
– sometimes highlighting in ISEs doesn’t work. However I expect that once namespace syntax will be consolidated, they would fix it immediately
– advanced tab expansion doesn’t work. For example Citrix\Logoff-Users, if you type Citrix, it works, if you type Citrix\, it doesn’t. Same applies for *x\ – won’t work. However because I work with frameworks, limitations to interactive sessions are not that important to me
Anyway, one more point to add. You are focusing on snapins\modules (where this functionality already exists, XenServer\Get-VM etc…), however for me functions are where I feel that namespaces are really missing.
Martin,
A couple of things:
> sometimes highlighting in ISEs doesn’t work
Would highlighting work for these in the PowerGUI Script Editor? Could be worth a try – after all it is a free download from http://powergui.org.
> however for me functions are where I feel that namespaces are really missing
Wouldn’t you be packaging your function libraries in modules in v2?
Dmitry
I tried it in PowerGUI already… It doesn’t highlight function if you use prefix\namespace. As I said, for me it is not huge issue, however it should be mentioned.
But I encountered bug in PowerGUI now – it doesn’t correctly highlight function when using function scopes, so it makes sense it doesn’t work for my scenario also (:-).
Only Global: scope is supported, I will write bug report for this.
In PSv2, I will definitely use modules. Problem is that I am specialized for enterprise deployment, so it will probably take 2 years before I will be able to start using it 😦 On the other hand, I am designing frameworks, so “fixing” namespaces in future is extremely simple for me. However even with PSv1 I would like to have function names in same format as they will be in PSv2 (at least because customers\consultants won’t need to learn new naming convention).
4 years ago I applied PSv1 naming convention to batch scripts in framework, so transition from batch to PSv1 was much easier for people involved (they were using same function names as before). And I would like to achieve same with PSv2.
Thanks for the feedback. We are working on updating and fixing our cmdlets and have the engineering team looking at your blog post now.
Thanks!
Pete Downing
Senior Product Manager, Provisioning services
Citrix Systems, Inc.
Hi Dmitry,
posted 🙂 http://martinzugec.blogspot.com/2009/03/powershell-naming-convention.html
Martin
When I first encountered PowerShell, the concept of a list of approved verbs struck me as strange – why do I have to use a list of verbs MS decided on? There will always be some actions in my product that do not fit into any of these verbs, and my existing customers will have to relearn what the commands mean. However, after a while I came to believe that perhaps a small set of verbs does make sense, in that it provides a uniform way to address actions. E.g., Instead of “Assign-User” I can use “Add-UserAssignment”. Fine.
But now there are 96 verbs. The list of “approved” verbs is well on its way to complete dilution. What is point of having 96 approved verbs? It’s not like users are going to understand or care about the difference between GET or SELECT or FIND or REQUEST. They want whatever is easy and fits the product. I’m sure PS3 will have 134 approved verbs. I see my example “assign” has been [arbitrarily] rejected for PS2.
Seriously, is there a point to these anymore? Why not just suggest the best-practice of using the verb-noun syntax for your cmdlets and forget the whole approved-verbs thing?
If my product has a “Wiggle” action and a “Sprocket” object, why do I need to find another way to convey “Wiggle-Sprocket”?
Wiggle-Sprocket at least looks fairly consistent – and OK if your customers understand what Wiggling is and are fine with seeing a warning when importing your module.
“Mcli-Add Device” and “Get-XenServer:VM.NameLabel” look completely non-PowerShell and this was what caused my concern – not non-standard verbs.