Automating the world one-liner at a time…
Recently, I saw someone that had developed a script on the CTP3 drop and was then having trouble running it on v1 of PowerShell. Eventually it turned out that he was using v2 features in his script. Most of you know that we are trying to keep the next version of PowerShell compatible with v1 and I encourage you to report any problems that you might have in that area. Unfortunately, v2 being compatible with v1, doesn’t mean v1 is compatible with v2.
After seeing that, I started thinking about people sharing v2 scripts on the web and the problems they might cause someone that didn’t realize the script was supposed to be run on v2. If you are sharing your v2 scripts (and I hope you are), then I wanted to say two things. Firstly, thanks! Sharing scripts helps the community tremendously. Secondly, if they are meant to be run only on v2, be sure to annotate them so people don’t get into trouble trying to run them on v1.
There are many ways you could annotate your scripts so people know what version they are supposed to be run on, but PowerShell already has a way to do it. It’s called #requires. You can read all about it here or here. I’m sure there are other places too, those are just the first ones I found.
In the majority of cases, all it will amount to is putting “#requires –version 2“ at the top of your script. For example, here’s my awesome script that will only run on v2.
#requires -version 2
write-host "Can only run on v2."
And here are the results on v2, followed by v1:
Can only run on v2.
PS > .\foo.ps1
The script 'foo.ps1' cannot be run because it contained a "#requires" statement at line 1 for Windows PowerShell versi
on 2.0 which is incompatible with the installed Windows PowerShell version of 1.0.
At line:1 char:10
+ .\foo.ps1 <<<<
- Marcel Ortiz Soto [MSFT]
PingBack from http://www.anith.com/?p=6484
Why not changing the file extension from ps1 to ps2? Seems more obvious to me...
Or do we have ps2 in PowerShell 3 to complete the Microsoft version numbering chaos?
Of course, the easiest way to prevent someone from running a version 2 script on a version 1 shell would have been to enforce renaming the 'required' file extension from .ps1 to .ps2 -- the extension's original intent.
Renaming the extension would be the best way to go, however, then we would need updated VIM plugins. That's ok though as the syntax plugin needs some minor parameter refactoring anyway;-)
Compatibility is important.
But I think this time Microsoft outperformed themselves.
So much that version 2 is installed in C:\Windows\system32\WindowsPowerShell\v1.0\
(On 32bit Vista, at least).
Unfortunately, I found out the hard way it is possible to write a script using V2 features and not even realize it.
For example, binding a new object to System.DirectoryServices.DirectoryEntry in v2 allows me to take advantage of the inherited 'children' method to enumerate the targeted object, however in v1 that isn't available to me because it appears to expect an overload. Not sure why this behavior would be different since this is the .Net namespace and not a PowerShell command, but it is. For some reason I thought it should work the same.
Renaming the extension is not enough. There will be differences between Win7 and WS2008R2 vs Vista/XP even if they are using v2 of PS.
I am hoping that when this RTM's or prior at least the helpfiles for the cmdlets will designate whether they are for v1 or 2 and which OS.
This doesn't appear to play nice with <# .SYNOPSIS #> comments. They both need to be on line 1 to work.