我们可以检查Powershell脚本所需的Powershell / WPF / .Net版本吗？

Question

I would like to be able to see how far back my scripts are compatible with earlier versions of software so, I'd like to see what the minimum version of Powershell, .Net and WPF that my scripts would require to run. I think I would be able to accomplish this if I knew how to retrieve information about each .Net class and PowerShell cmdlet and what version they were introduced in.

EDIT:

I probably wasn't have been clear enough so here are some examples found manually online. However, I would like to be able to get this information via PowerShell. But as Ansgar Wiechers stated this information may not be available very easily. I was just hoping someone might've already done this or knew how to obtain that information.

For example.

[System.Net.NetworkInformation.Ping] - Available since .Net 2.0 (Found at https://msdn.microsoft.com/en-us/library/system.net.networkinformation.ping(v=vs.110).aspx#Anchor_8 )

Get-CIMInstance - available since Powershell 3.0 (Found https://blogs.msdn.microsoft.com/powershell/2012/08/24/introduction-to-cim-cmdlets/ in the first paragraph)

Answer 1

Edited based on the OP's clarification

If you are looking for cmdlets released per WMF version as noted by your links...

'Available since .Net 2.0' 'available since Powershell 3.0'

... then, TechNet provides that here:

PowerShell 1.0 Cmdlets These are the list of cmdlets which can be used in the Windows PowerShell 1.0. https://social.technet.microsoft.com/wiki/contents/articles/13769.powershell-1-0-cmdlets.aspx

PowerShell 2.0 Cmdlets These are the list of cmdlets which can be used in the Windows PowerShell 2.0. https://social.technet.microsoft.com/wiki/contents/articles/13876.powershell-2-0-cmdlets.aspx

PowerShell 3.0 Cmdlets These are the cmdlets, aliases, and functions available in the Windows 8 Developer Preview.
https://social.technet.microsoft.com/wiki/contents/articles/4694.powershell-3-cmdlets.aspx

Note there is no such listing like the above for v4 - v6 (PowerShellCore) that I've ever found.

But there is this: This topic lists the system requirements for Windows PowerShell 3.0, Windows PowerShell 4.0 and Windows PowerShell 5.0, and for special features, such as Windows PowerShell Integrated Scripting Environment (ISE), CIM commands, and workflows. https://docs.microsoft.com/en-us/powershell/scripting/setup/windows-powershell-system-requirements?view=powershell-5.1

Considering what you are after. If this were me. My beginning approach would be to stand up a pristine set of VM clients (or hand off to someone we'd know who had them) with the appropriate OS's, installed with the RTM WMF version for the OS and run the below, saved to a file.

Then use that file as the base compare to the code. Meaning, use a Select-String on all my modules, functions and scripts and matching on cmdlet name to get the other properties in the compare file into a code compare report.

Any cmdlet name matches, could be the baseline indicator the code scanned had a cmdlet used from a particular PoSH version. Thus giving the assumption that the code scanned was written either on the OS WMF RTM version or written for a given WMF version using the -version switch.

Report host OS, WMF and CLR version information

$OSVersion = (Get-WmiObject -Class Win32_OperatingSystem).Caption
Get-Command | Where CommandType -Match cmdlet | 
Select Name, Version,
@{Name = 'PSCompatible';Expression = {$PSVersionTable.PSCompatibleVersions}},
@{Name = 'CLR';Expression = {$PSVersionTable.CLRVersion}},
@{Name = 'WSMan';Expression = {$PSVersionTable.WSManStackVersion}},
@{Name = 'Remoting';Expression = {$PSVersionTable.PSRemotingProtocolVersion}},
@{Name = 'OS';Expression = {$OSVersion}} | 
Sort-Object Version | Format-Table -AutoSize


Name                        Version     PSCompatible            CLR             WSMan Remoting OS                      
----                        -------     ----------              ---             ----- -------- --                      
Enable-SqlAlwaysOn          1.0         {1.0, 2.0, 3.0, 4.0...} 4.0.30319.42000 3.0   2.3      Microsoft Windows 10 Pro
Set-SqlAuthenticationMode   1.0         {1.0, 2.0, 3.0, 4.0...} 4.0.30319.42000 3.0   2.3      Microsoft Windows 10 Pro
Disable-SqlAlwaysOn         1.0         {1.0, 2.0, 3.0, 4.0...} 4.0.30319.42000 3.0   2.3      Microsoft Windows 10 Pro
Set-RuleOption              1.0         {1.0, 2.0, 3.0, 4.0...} 4.0.30319.42000 3.0   2.3      Microsoft Windows 10 Pro
Set-HVCIOptions             1.0         {1.0, 2.0, 3.0, 4.0...} 4.0.30319.42000 3.0   2.3      Microsoft Windows 10 Pro
...


Get summary cmdlets by cmdlet version
Get-Command | Group-Object Version | Sort-Object Name -Descending | Format-Table -AutoSize


Count Name        Group                                                                                                                               
----- ----        -----                                                                                                                               
   37 4.2.3       {Add-NTFSAccess, Add-NTFSAudit, Clear-NTFSAccess, Clear-NTFSAudit...}                                                               
   33 4.0.6       {Add-AssertionOperator, AfterAll, AfterEach, AfterEachFeature...}                                                                   
  196 3.1.0.0     {ConvertFrom-SddlString, Format-Hex, Get-FileHash, Import-PowerShellDataFile...}                                                    
   97 3.0.0.0     {Add-History, Add-PSSnapin, Clear-History, Connect-PSSession...}                                                                    
...

My last thought on this however, is, why this effort?

We know the legacy code will work in later versions and later version specific module/cmdlets/switches will most likely not work natively in legacy OS / PS versions. Well unless you manually, hack at stuff, copy them there or proxy them there using remoting, doing stuff like the below.

 Use using current version cmdlets while on a legacy OS, i.e, Win7SP1 needing to use Test-NetConnection

$RemotePoSHModuleUNCFolder = '\\WS2012r2\$C\Windows\System32\WindowsPowerShell\v1.0\Modules'
$LocalhostPoSHModuleUNCFolder = 'C:\Windows\System32\WindowsPowerShell\v1.0\Modules'
'NetTCPIP','DnsClient','NetSecurity' `
| % {Copy-Item -Path $RemotePoSHModuleUNCFolder\$_ -Destination $LocalhostPoSHModuleUNCFolder}

'NetTCPIP','DnsClient','NetSecurity' `
| % {Import-Module -Name "C:\Windows\System32\WindowsPowerShell\v1.0\Modules\$_" -Verbose}

# Use cmdlet proxy, import module from remote machine WS201R2
$W2K12RemoteSession = New-PSSession -ComputerName 'WS2K12'
Import-Module NetTCPIP -PSSession $W2K12RemoteSession

With the MS announced depreciation of v2, and v2 having issues if .Net 4x is on the host as per this:

"Using PowerShell 2.0 with .NET Framework 4.0 is not supported. This is due to some changes in the runtime activation policy of CLR 4 which prevent applications built against CLR 2 from automatically rolling forward to CLR 4."

With further detail here: https://msdn.microsoft.com/en-us/magazine/ee819091.aspx

Unless you have legacy OS's with V2 and below, I am not sure what comparing for would buy you.

But you post sounds like a good idea for an addition to PSScriptAnalyzer.