Сценарій PowerShell для повернення версій .NET Framework на машині?


182

Що буде сценарієм PowerShell для повернення версій .NET Framework на машині?

Моя перша здогадка - це щось, що стосується WMI. Чи є щось краще?

Він повинен бути однолінійним, щоб повертати лише останню версію для кожної установки .NET [у кожному рядку].


7
Машина може (і буде) мати кілька версій Fx. Як ти хочеш це впоратися? І тут є безлад Fx2 .. Fx3.5SP1. Яку версію ви хочете почути?
Хенк Холтерман

Я припускаю, що потрібно було б повернути повний номер версії для кожної установки.
MattUebel

1
Чи не існує способу зробити це через WMI?
Марк Річман

Ви попросили PowerShell, я щось зробив для C # (консольний додаток). Якщо вам цікаво, ось воно ...
Метт

Дійсно неймовірно, що не щось подібне:asp.net -v
Altimus Prime

Відповіді:


354

Якщо ви збираєтеся використовувати реєстр, вам доведеться повторити, щоб отримати повну версію для 4.x Framework. Раніші відповіді обидва повертають корінь у моїй системі для .NET 3.0 (де числа WCF та WPF, які вкладені під 3.0, вище), я не можу це пояснити), і не вдалося повернути нічого за 4.0. .

EDIT: Для .Net 4.5 і вище, це знову змінилося, тому тут є чудова стаття MSDN, в якій пояснюється, як перетворити значення Release у номер версії .Net, це загальна аварія поїзда :-(

Мені це подобається (зауважте, що він видає окремі номери версій WCF & WPF на 3.0. Я не знаю, про що йдеться). Він також виводить і Client, і Full на 4.0 (якщо у вас їх встановлено обидва):

Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -recurse |
Get-ItemProperty -name Version,Release -EA 0 |
Where { $_.PSChildName -match '^(?!S)\p{L}'} |
Select PSChildName, Version, Release

На основі статті MSDN ви можете створити таблицю пошуку та повернути номер версії маркетингового продукту для випусків після 4,5:

$Lookup = @{
    378389 = [version]'4.5'
    378675 = [version]'4.5.1'
    378758 = [version]'4.5.1'
    379893 = [version]'4.5.2'
    393295 = [version]'4.6'
    393297 = [version]'4.6'
    394254 = [version]'4.6.1'
    394271 = [version]'4.6.1'
    394802 = [version]'4.6.2'
    394806 = [version]'4.6.2'
    460798 = [version]'4.7'
    460805 = [version]'4.7'
    461308 = [version]'4.7.1'
    461310 = [version]'4.7.1'
    461808 = [version]'4.7.2'
    461814 = [version]'4.7.2'
    528040 = [version]'4.8'
    528049 = [version]'4.8'
}

# For One True framework (latest .NET 4x), change the Where-Object match 
# to PSChildName -eq "Full":
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -Recurse |
  Get-ItemProperty -name Version, Release -EA 0 |
  Where-Object { $_.PSChildName -match '^(?!S)\p{L}'} |
  Select-Object @{name = ".NET Framework"; expression = {$_.PSChildName}}, 
@{name = "Product"; expression = {$Lookup[$_.Release]}}, 
Version, Release

Насправді, оскільки мені постійно доводиться оновлювати цю відповідь, ось сценарій для генерування вищезазначеного сценарію (з невеликою кількістю зайвих) з джерела розмітки для цієї веб-сторінки. Це, певно, порушиться в якийсь момент, тому я зберігаю поточну копію вище.

# Get the text from github
$url = "https://raw.githubusercontent.com/dotnet/docs/master/docs/framework/migration-guide/how-to-determine-which-versions-are-installed.md"
$md = Invoke-WebRequest $url -UseBasicParsing
$OFS = "`n"
# Replace the weird text in the tables, and the padding
# Then trim the | off the front and end of lines
$map = $md -split "`n" -replace " installed [^|]+" -replace "\s+\|" -replace "\|$" |
    # Then we can build the table by looking for unique lines that start with ".NET Framework"
    Select-String "^.NET" | Select-Object -Unique |
    # And flip it so it's key = value
    # And convert ".NET FRAMEWORK 4.5.2" to  [version]4.5.2
    ForEach-Object { 
        [version]$v, [int]$k = $_ -replace "\.NET Framework " -split "\|"
        "    $k = [version]'$v'"
    }

# And output the whole script
@"
`$Lookup = @{
$map
}

# For extra effect we could get the Windows 10 OS version and build release id:
try {
    `$WinRelease, `$WinVer = Get-ItemPropertyValue "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" ReleaseId, CurrentMajorVersionNumber, CurrentMinorVersionNumber, CurrentBuildNumber, UBR
    `$WindowsVersion = "`$(`$WinVer -join '.') (`$WinRelease)"
} catch {
    `$WindowsVersion = [System.Environment]::OSVersion.Version
}

Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -Recurse |
    Get-ItemProperty -name Version, Release -EA 0 |
    # For The One True framework (latest .NET 4x), change match to PSChildName -eq "Full":
    Where-Object { `$_.PSChildName -match '^(?!S)\p{L}'} |
    Select-Object @{name = ".NET Framework"; expression = {`$_.PSChildName}}, 
                @{name = "Product"; expression = {`$Lookup[`$_.Release]}}, 
                Version, Release,
    # Some OPTIONAL extra output: PSComputerName and WindowsVersion
    # The Computer name, so output from local machines will match remote machines:
    @{ name = "PSComputerName"; expression = {`$Env:Computername}},
    # The Windows Version (works on Windows 10, at least):
    @{ name = "WindowsVersion"; expression = { `$WindowsVersion }}
"@

Це саме те, що я шукаю, але мені важко обернути свою думку навколо того, що саме це робить. З того, що я розумію, він виходить до реєстру NDP і рекурсивно шукає кожну папку, яка відповідає '^(?!S)\p{L}'регексу та отримує інформацію про версію та випуск. Який саме цей регулярний вираз намагається кваліфікувати?
Джонрад

2
@Johnrad PSChildName- це назва листа ключа реєстру. \p{L}- будь-який символ у літері категорії "Юнікод". (?!S)- це негативний погляд навколо, і ^це початок рядка. Тож треба починати з іншого листа S. Тож якщо ви розглядаєте лише ASCII, це те саме, що $_.PSChildName -cmatch '^[A-RT-Za-z]'(зверніть увагу -cmatch). Таким чином, він знаходить ключі, де назва починається з літери, відмінної від S. Я поняття не маю, чому ви б не піклувалися про не-ASCII, якщо ви фільтруєте імена, починаючи з S... Однозначно з вами на цьому, що це так заплутано.
jpmc26

1
Тепер я більше плутаю те, що чорт Get-ItemProperty -name Version,Release -EA 0робить. Я знаю, -EA 0це те саме, що -ErrorAction SilentlyContinue, але який ефект буде Get-ItemProperty -name Version,Releaseмати, коли підключити всі результати до нього? Здається, це не позбавляє змінних об'єкта, оскільки інші використовуються в пізніших командах конвеєра. Він запускається, помиляється, коли у ключа відсутнє ім'я Versionабо Releaseім'я, а потім передає об'єкти, де це вдалося, у наступну команду в конвеєрі?
jpmc26

3
Get-ChildItem повертає ВСІ підрозділи реєстру (якщо потрібно) підпапки). Get-ItemProperty повертає значення (зокрема: "Версія" та "Випуск") - ми ігноруємо помилки, оскільки нам не байдуже папки, які не мають цих значень. Так, так, в основному ми знаходимо КОЖНУ підпапку, а потім шукаємо Версію або Випуск (будь-які папки без однієї або обох з них ігноруються).
Джейкуль

3
Дивовижно! Я лише змінив (?!S)пункт, щоб він (?![SW])надалі виключив записи "Windows *". Це також можна зробити, (?=[vCF])оскільки єдиними клавішами, які нас дійсно цікавлять, є корені версії та клавіші "Повний" та "Клієнт" для .NET 4.0+. ;)
Chiramisu

27
gci 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' |
sort pschildname -des                                  |
select -fi 1 -exp pschildname

Ця відповідь не повертає 4,5, якщо це встановлено. Відповідь нижче від @Jaykul та використання рекурсу є.


5
gci 'HKLM: \ SOFTWARE \ Microsoft \ NET Framework Setup \ NDP' | сортувати pschildname -des | foreach-object {$ _. ім'я; $ _. GetValue ("Версія");}
MattUebel

для мене відповідь зараз на вершині, ось ось посилання на неї :-): stackoverflow.com/a/3495491/1747983
Тіло

1
Встановивши .NET 4.7.1 в Windows 10, це все ще повертає v4.0.
Метт

24

Додано підтримку сценарію v4.8:

Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -recurse |
Get-ItemProperty -name Version,Release -EA 0 |
Where { $_.PSChildName -match '^(?![SW])\p{L}'} |
Select PSChildName, Version, Release, @{
  name="Product"
  expression={
      switch -regex ($_.Release) {
        "378389" { [Version]"4.5" }
        "378675|378758" { [Version]"4.5.1" }
        "379893" { [Version]"4.5.2" }
        "393295|393297" { [Version]"4.6" }
        "394254|394271" { [Version]"4.6.1" }
        "394802|394806" { [Version]"4.6.2" }
        "460798|460805" { [Version]"4.7" }
        "461308|461310" { [Version]"4.7.1" }
        "461808|461814" { [Version]"4.7.2" }
        "528040|528049" { [Version]"4.8" }
        {$_ -gt 528049} { [Version]"Undocumented version (> 4.8), please update script" }
      }
    }
}

21
[environment]::Version

Надає вам примірник Versionдля CLR, який використовує поточна копія PSH (як тут задокументовано ).


3
У мене встановлено .NET 4, але PowerShell буде використовувати лише час виконання 2.0. Тож це насправді не допомагає.
Джої

@Johannes: Дивіться коментар до свого Q, вам потрібно чітко пояснити, що ви хочете.
Річард

9
Для Powershell 2.0 ви також $PSVersionTableможете знайти версію CLR PowerShell, на якій працює.
Кіт Хілл

6
Як щодо вищих версій? У мене є .NET 4.7.1 зараз, а сценарій завжди повертає 4.0.30319 Rev. 42000.
Метт

@Matt Вам знадобиться перекласти незначну частину версії ... і зауважте, залежно від того, що встановлено в налаштуваннях Powershell, можливо, вона не використовує останню мінорну / патч-версію.
Річард

13

Правильний синтаксис:

[System.Runtime.InteropServices.RuntimeEnvironment]::GetSystemVersion()
#or
$PSVersionTable.CLRVersion

GetSystemVersionФункція повертає рядок , як це:

v2.0.50727        #PowerShell v2.0 in Win 7 SP1

або як це

v4.0.30319        #PowerShell v3.0 (Windows Management Framework 3.0) in Win 7 SP1

$PSVersionTable- об'єкт, доступний лише для читання. Властивість CLRVersion - це структурований номер версії, такий:

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      30319  18444   

1
Я спробував це на win8, він нічого не повертає. У Windows 7 він повертає 2, тоді як 4.5.1 вже встановлений. Я не знаю, чому це не можна використовувати на нових платформах. На win sesrver 2008 він працює.
макс.

Перший варіант працює в моєму 64-бітному середовищі Windows 8. Другий варіант працює, але я думаю, що якраз і показує версію .NET, що працює поточний екземпляр PowerShell, який майже завжди є останнім. (Редагувати: Можливо, вони обидва.)
Ваймс

те ж саме. у Windows 7 у мене є .net 2.0 та 4.0, але команда показує лише v2.0.50727. Використовуйте підхід Джейкула.
макс

Версія Clr не відповідає рамковій версії, 4+ фреймворків базуються на 4
клр

Як щодо вищих версій? У мене є .NET 4.7.1 зараз, і сценарій завжди повертає 4.0.30319 Rev. 42000.
Метт

11

Я знайшов це завдяки заповненню вкладок у powershell для OSX:

[System.Runtime.InteropServices.RuntimeInformation]::get_FrameworkDescription() .NET Core 4.6.25009.03


1
Так, він повертає .NET Framework 4.7.2558.0 - але як можна відрізнити 4.7 від 4.7.1 (у мене на машині Windows 10 у мене 4.7.1).
Метт

1
[version]([Runtime.InteropServices.RuntimeInformation]::FrameworkDescription -replace '^.[^\d.]*','')
Рабаш



2

Приємне рішення

Спробуйте скористатись завантажуваним модулем DotNetVersionLister (на основі даних реєстру та деякої таблиці пошуку версій до маркетингу).

Які б використовувались так:

PS> Get-DotNetVersion -LocalHost -nosummary


ComputerName : localhost
>=4.x        : 4.5.2
v4\Client    : Installed
v4\Full      : Installed
v3.5         : Installed
v3.0         : Installed
v2.0.50727   : Installed
v1.1.4322    : Not installed (no key)
Ping         : True
Error        :

Або так, якщо ви просто хочете перевірити його на якусь .NET Framework> = 4. * :

PS> (Get-DotNetVersion -LocalHost -nosummary).">=4.x"
4.5.2

Але це не буде працювати (встановити / імпортувати), наприклад, з PS v2.0 ( Win 7 , стандарт Win Server 2010 ) через несумісність ...

Нижче наведено мотивацію функцій "спадщини"

(Ви можете пропустити читання цього і використовувати код нижче)

Нам довелося працювати з PS 2.0 на деяких машинах і не вдалося встановити / імпортувати вищевказаний DotNetVersionLister .
На інших машинах ми хотіли оновити (з PS 2.0 ) до PS 5.1 (що в свою чергу потребує .NET Framework> = 4.5 ) за допомогою двох фірмових налаштувань Install-DotnetLatestCompanyі Install-PSLatestCompany.
Щоб добре провести адміністраторів через процес встановлення / оновлення, нам доведеться визначити версію .NET у цих функціях на всіх машинах та версіях PS.
Таким чином, ми також використовували наведені нижче функції, щоб визначити їх безпечніше у будь-яких умовах ...

Функції для застарілих середовищ PS (наприклад, PS v2.0 )

Отже, наступний код та нижче (витягнуті) приклади використання корисні тут (на основі інших відповідей тут):

function Get-DotNetVersionByFs {
  <#
    .SYNOPSIS
      NOT RECOMMENDED - try using instead:
        Get-DotNetVersion 
          from DotNetVersionLister module (https://github.com/EliteLoser/DotNetVersionLister), 
          but it is not usable/importable in PowerShell 2.0 
        Get-DotNetVersionByReg
          reg(istry) based: (available herin as well) but it may return some wrong version or may not work reliably for versions > 4.5 
          (works in PSv2.0)
      Get-DotNetVersionByFs (this):  
        f(ile) s(ystem) based: determines the latest installed .NET version based on $Env:windir\Microsoft.NET\Framework content
        this is unreliable, e.g. if 4.0* is already installed some 4.5 update will overwrite content there without
        renaming the folder
        (works in PSv2.0)
    .EXAMPLE
      PS> Get-DotnetVersionByFs
      4.0.30319
    .EXAMPLE
      PS> Get-DotnetVersionByFs -All
      1.0.3705
      1.1.4322
      2.0.50727
      3.0
      3.5
      4.0.30319
    .NOTES
      from https://stackoverflow.com/a/52078523/1915920
  #>
    [cmdletbinding()]
  param(
    [Switch]$All  ## do not return only latest, but all installed
  )
  $list = ls $Env:windir\Microsoft.NET\Framework |
    ?{ $_.PSIsContainer -and $_.Name -match '^v\d.[\d\.]+' } |
    %{ $_.Name.TrimStart('v') }
  if ($All) { $list } else { $list | select -last 1 }
}


function Get-DotNetVersionByReg {
  <#
    .SYNOPSIS
      NOT RECOMMENDED - try using instead:
        Get-DotNetVersion
          From DotNetVersionLister module (https://github.com/EliteLoser/DotNetVersionLister), 
          but it is not usable/importable in PowerShell 2.0. 
          Determines the latest installed .NET version based on registry infos under 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP'
    .EXAMPLE
        PS> Get-DotnetVersionByReg
        4.5.51209
    .EXAMPLE
        PS> Get-DotnetVersionByReg -AllDetailed
        PSChildName                                          Version                                             Release
        -----------                                          -------                                             -------
        v2.0.50727                                           2.0.50727.5420
        v3.0                                                 3.0.30729.5420
        Windows Communication Foundation                     3.0.4506.5420
        Windows Presentation Foundation                      3.0.6920.5011
        v3.5                                                 3.5.30729.5420
        Client                                               4.0.0.0
        Client                                               4.5.51209                                           379893
        Full                                                 4.5.51209                                           379893
    .NOTES
      from https://stackoverflow.com/a/52078523/1915920
  #>
    [cmdletbinding()]
    param(
        [Switch]$AllDetailed  ## do not return only latest, but all installed with more details
    )
    $Lookup = @{
        378389 = [version]'4.5'
        378675 = [version]'4.5.1'
        378758 = [version]'4.5.1'
        379893 = [version]'4.5.2'
        393295 = [version]'4.6'
        393297 = [version]'4.6'
        394254 = [version]'4.6.1'
        394271 = [version]'4.6.1'
        394802 = [version]'4.6.2'
        394806 = [version]'4.6.2'
        460798 = [version]'4.7'
        460805 = [version]'4.7'
        461308 = [version]'4.7.1'
        461310 = [version]'4.7.1'
        461808 = [version]'4.7.2'
        461814 = [version]'4.7.2'
    }
    $list = Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -Recurse |
        Get-ItemProperty -name Version, Release -EA 0 |
        # For One True framework (latest .NET 4x), change match to PSChildName -eq "Full":
        Where-Object { $_.PSChildName -match '^(?!S)\p{L}'} |
        Select-Object `
           @{
               name = ".NET Framework" ; 
               expression = {$_.PSChildName}}, 
           @{  name = "Product" ; 
               expression = {$Lookup[$_.Release]}}, 
           Version, Release
    if ($AllDetailed) { $list | sort version } else { $list | sort version | select -last 1 | %{ $_.version } }
}

Приклад використання:

PS> Get-DotNetVersionByFs
4.0.30319

PS> Get-DotNetVersionByFs -All
1.0.3705
1.1.4322
2.0.50727
3.0
3.5
4.0.30319

PS> Get-DotNetVersionByReg
4.5.51209

PS> Get-DotNetVersionByReg -AllDetailed

.NET Framework                   Product Version        Release
--------------                   ------- -------        -------
v2.0.50727                               2.0.50727.5420
v3.0                                     3.0.30729.5420
Windows Communication Foundation         3.0.4506.5420
Windows Presentation Foundation          3.0.6920.5011
v3.5                                     3.5.30729.5420
Client                                   4.0.0.0
Client                           4.5.2   4.5.51209      379893
Full                             4.5.2   4.5.51209      379893

Щоб не бачити використання таймінгів(Get-DotNetVersion -LocalHost -nosummary).">=4.x"
ΩmegaMan

@ ΩmegaMan: thx - оновив вашу хорошу рекомендацію у відповідь вище :)
Андреас Дітріх

1

Не дуже. Однозначно не дуже:

ls $Env:windir\Microsoft.NET\Framework | ? { $_.PSIsContainer } | select -exp Name -l 1

Це може бути, а може і не спрацювати. Але що стосується останньої версії, то ця програма повинна бути досить надійною, оскільки є по суті порожні папки для старих версій (1.0, 1.1), але не новіші - вони з'являються лише після встановлення відповідної рамки.

Але я підозрюю, що тут повинен бути кращий шлях.


Вам потрібно ще трохи фільтрувати, "V [.0-9] +" повинен обмежувати відповідність папкам .NET (у мене там є деякі інші папки). А потім перевірте, чи справді встановлено ... WMI на встановлених компонентах може бути простішим.
Річард

Гм, правильно ... на цій машині також є кілька інших папок - у мене на іншій машині було лише безліч інших файлів. Хоча ця вся відповідь була скоріше випадком «роботи для мене». Я впевнений, що існує надійний і призначений спосіб отримання цієї інформації.
Joey

6
psake (інструмент автоматизації побудови) застосовує подібний підхід і успішно використовує його (або принаймні ніхто не змінював його через проблему). Але це правда, що їм не потрібна повна версія фреймворку ... Для мого комп'ютера це стає ближче:ls $Env:windir\Microsoft.NET\Framework | ? { $_.PSIsContainer -and $_.Name -match '^v\d.[\d\.]+' } | % { $_.Name.TrimStart('v') }
stej

З усіх однолінійних відповідей той, який надає stej, є найчистішим і працює як очікується. Якби це була відповідь, я би проголосував за неї.
Братч

На жаль, це не є надійним. Зараз у мене .NET 4.7.1 , і сценарій завжди повертає v4.0.30319.
Метт

0

Якщо на комп'ютері встановлено Visual Studio, відкрийте командний рядок для розробників Visual Studio і введіть таку команду: clrver

Він перерахує всі встановлені версії .NET Framework на цій машині.


Ця команда отримує версію CLR, а не версію .NET Framework - що відрізняється.
користувач11909

0

Ось я вирішу це питання, слідуючи документації msft :

$gpParams = @{
    Path        = 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full'
    ErrorAction = 'SilentlyContinue'
}
$release = Get-ItemProperty @gpParams | Select-Object -ExpandProperty Release

".NET Framework$(
    switch ($release) {
        ({ $_ -ge 528040 }) { ' 4.8'; break }
        ({ $_ -ge 461808 }) { ' 4.7.2'; break }
        ({ $_ -ge 461308 }) { ' 4.7.1'; break }
        ({ $_ -ge 460798 }) { ' 4.7'; break }
        ({ $_ -ge 394802 }) { ' 4.6.2'; break }
        ({ $_ -ge 394254 }) { ' 4.6.1'; break }
        ({ $_ -ge 393295 }) { ' 4.6'; break }
        ({ $_ -ge 379893 }) { ' 4.5.2'; break }
        ({ $_ -ge 378675 }) { ' 4.5.1'; break }
        ({ $_ -ge 378389 }) { ' 4.5'; break }
        default { ': 4.5+ not installed.' }
    }
)"

Цей приклад працює з усіма версіями PowerShell і буде працювати постійно, оскільки 4.8 - остання версія .NET Framework.


-1

Ось загальна ідея:

Отримати дочірні елементи в каталозі .NET Framework - це контейнери, назви яких відповідають шаблону v номер крапки . Сортуйте їх за спаданням імені, візьміть перший об’єкт і поверніть його властивість імені.

Ось сценарій:

(Get-ChildItem -Path $Env:windir\Microsoft.NET\Framework | Where-Object {$_.PSIsContainer -eq $true } | Where-Object {$_.Name -match 'v\d\.\d'} | Sort-Object -Property Name -Descending | Select-Object -First 1).Name

Я встановив 4.6.1 , але ваш скрипт повертає v4.0.30319
грабують

Це не працює на моїй машині (у мене встановлено 4.7.1). Він друкує v4.0.30319
Метт

-1

Я б спробував це в PowerShell: Працював для мене!

(Get-ItemProperty "HKLM: Програмне забезпечення \ Microsoft \ NET Framework Setup \ NDP \ v4 \ Full").


Це не говорить вам правди. Номер версії там скаже, наприклад, 4.7.03056, коли версія продукту 4.7.2
Jaykul

-2

Мені не до синтаксису PowerShell, але я думаю, ви могли просто зателефонувати System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVersion () . Це поверне версію у вигляді рядка ( v2.0.50727я думаю, щось подібне ).


2
Для поточного часу виконання, не обов’язково останнього встановленого.
Джої

Для корпусу повноважень правильним синтаксисом є:, [System.Runtime.InteropServices.RuntimeEnvironment]::GetSystemVersion()але він просто повертає v4.0.30319, навіть якщо v4.6 встановлений у моєму випадку.
Метт

@matt 4.0.30319 - це версія CLR від .Net Framework 4.0 до .Net Framework 4.7.1. Тож ваша версія v4.6 фактично використовує 4.0.30319 як її CLR-версію. Зауважте, що лише Ревізійна частина Версії - це різниця між усіма .Net Frameworks. Дивіться також: .NET Версії та залежності - Microsoft Docs
walterlv

@walterlv - Дякую за посилання. Так, я це знаю. Microsoft зробила велику помилку, зробивши це, нелегко віддалено підключитися до сервера і з’ясувати, яка саме .net версія саме там фактично встановлена. Ще один великий головний біль для адміністраторів та розробників.
Метт

І це може допомогти також: Microsoft: Як визначити версії та рівні пакетів обслуговування .NET Framework . Це також показує, наскільки складно було з’ясувати, що саме встановлено на вашій машині ... :-(
Метт

-2

Це деривіт попереднього допису, але це отримує останню версію .net Framework 4 в моїх тестах.

get-itemproperty -name version,release "hklm:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\FULL"

Що дозволить викликати команду на віддаленій машині:

invoke-command -computername server01 -scriptblock {get-itemproperty -name version,release "hklm:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\FULL" | select pscomputername,version,release} 

Що встановлює таку можливість за допомогою префікса ADModule та іменування:

get-adcomputer -Filter 'name -like "*prefix*"' | % {invoke-command -computername $_.name -scriptblock {get-itemproperty -name version,release "hklm:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\FULL" | select pscomputername,version,release} | ft
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.