My first guess is something involving WMI. Does anybody know better?
Clarification: One-Liner to return only the latest version for each installation of .NET
A:
I'm not up on my PowerShell syntax, but I think you could just call System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVerison(). This will return the version as a string (something like v2.0.50727, I think).
Andy
2010-08-15 12:05:08
For the currently executing runtime, not necessarily the latest installed one.
Joey
2010-08-15 13:47:12
+2
A:
[environment]::Version
Gives you an instance of Version for the CLR the current copy of PSH is using (as documented here).
Richard
2010-08-15 12:25:54
I have .NET 4 installed but PowerShell will only use the 2.0 runtime. So that's not really of help here.
Joey
2010-08-15 13:41:41
@Johannes: See comment on your Q, you need to be explicit about what you want.
Richard
2010-08-15 13:52:29
For Powershell 2.0, you can also use `$PSVersionTable` to find the version of the CLR PowerShell is running on.
Keith Hill
2010-08-15 18:07:54
+2
A:
Not pretty. Definitely not pretty:
ls $Env:windir\Microsoft.NET\Framework | ? { $_.PSIsContainer } | select -exp Name -l 1
This may or may not work. But as far as the latest version is concerned this should be pretty reliable, as there are essentially empty folders for old versions (1.0, 1.1) but not newer ones – those only appear once the appropriate framework is installed.
Still, I suspect there must be a better way.
Joey
2010-08-15 13:43:18
You need to filter a little more, "V[.0-9]+" should limit the match to the .NET folders (I have some other folders there). And then check there is a real install... WMI on installed components might be easier.
Richard
2010-08-15 13:55:46
Hm, right ... on this machine there are a few other folders as well – I had only a bunch of other files on my other machine. This whole answer was more of a case of »works for me«, though. I'm sure there is a reliable and intended way of getting that information.
Joey
2010-08-15 15:56:00
psake (build automation tool) takes a similar approach and uses it successfully (or at least nobody changed it because of an issue). But it's true that they don't need full framework version... For my computer this gets closer: `ls $Env:windir\Microsoft.NET\Framework | ? { $_.PSIsContainer -and $_.Name -match '^v\d.[\d\.]+' } | % { $_.Name.TrimStart('v') }`
stej
2010-08-17 05:07:13
Of all the one-liners in the answers, the one provided by stej is the cleanest and works as expected. If it was answer I would have voted for it.
Bratch
2010-08-21 16:09:35
+1
A:
There's no reliable way to do this for all platforms and architectures using a simple script. If you want to learn how to do it reliably, start here:
http://blogs.msdn.com/b/astebner/archive/2006/08/02/687233.aspx
-Oisin
x0n
2010-08-15 17:06:50
+3
A:
gci 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' | sort pschildname -des | select -fi 1 -exp pschildname
Jason Stangroome
2010-08-16 07:03:29
+1
A:
If you're going to use the registry you have to recurse in order to get the full version for the 4.0 Framework. The earlier answers both return the root number on my system for .Net 3.0 (where the WCF and WPF numbers, which are nested under 3.0, are higher -- I can't explain that), and fail to return anything for 4.0 ...
This looks right to me (note that it outputs separate version numbers for WCF & WPF on 3.0, I don't know what that's about). It also outputs both Client and Full on 4.0 (if you have them both installed):
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -recurse |
Get-ItemProperty Version -EA 0 |
Where { $_.PSChildName -match '^(?!S)\p{L}'} |
Select PSChildName, Version
Jaykul
2010-08-16 17:09:24