如何用PowerShell查询IIS托管网站的.NET运行版本

Hey there! I’ve been in your shoes before—trying to dig up .NET versions for IIS apps can feel like hunting for a needle in a haystack when the Web Admin module comes up short. Let me share a few reliable PowerShell methods that’ll get you the info you need.

The most straightforward way is to look at the managed runtime version configured for each IIS app pool. This tells you the .NET Framework runtime the app is using to run.

Run this PowerShell command (you’ll need the IIS Administration module installed, which it sounds like you already have):

Get-IISAppPool | Select-Object Name, ManagedRuntimeVersion, State

• ManagedRuntimeVersion: This field shows the CLR version tied to the app pool. For example, v4.0 maps to all .NET Framework 4.x versions (4.5, 4.7.2, 4.8, etc.), while v2.0 covers .NET Framework 2.0, 3.0, and 3.5.
• If the value is blank or No Managed Code, the app pool isn’t running .NET Framework code (e.g., static sites, Node.js apps, or .NET Core/.NET 5+ apps).

Many ASP.NET apps specify the target .NET Framework version in their web.config file. This is the version the app was compiled against, which is useful to confirm compatibility with the runtime.

Use this script to scan your website root for web.config files and extract the target framework:

# Replace this with your actual website root directory
$websiteRoot = "C:\inetpub\wwwroot"

Get-ChildItem -Path $websiteRoot -Filter "web.config" -Recurse | ForEach-Object {
    $xmlContent = [xml](Get-Content $_.FullName)
    $targetFramework = $xmlContent.configuration.system.web.compilation.targetFramework
    
    [PSCustomObject]@{
        ApplicationPath = $_.Directory.FullName.Replace($websiteRoot, "")
        TargetFramework = if ($targetFramework) { $targetFramework } else { "Not specified" }
        ConfigFile      = $_.FullName
    }
}

• The targetFramework value will look like 4.8 or 3.5, directly indicating the .NET Framework version the app was built for.

To get a complete picture (runtime + compiled version), you can merge the two datasets. This is especially helpful if your app names align with your app pool names:

# Grab app pool runtime info
$appPools = Get-IISAppPool | Select-Object Name, ManagedRuntimeVersion

# Grab web.config target framework info
$websiteRoot = "C:\inetpub\wwwroot"
$webConfigData = Get-ChildItem -Path $websiteRoot -Filter "web.config" -Recurse | ForEach-Object {
    $xmlContent = [xml](Get-Content $_.FullName)
    [PSCustomObject]@{
        AppDirectory = $_.Directory.FullName
        TargetFramework = $xmlContent.configuration.system.web.compilation.targetFramework
    }
}

# Match app pools to their corresponding apps (adjust the matching logic if needed)
$appPools | ForEach-Object {
    $pool = $_
    $matchingConfig = $webConfigData | Where-Object { $_.AppDirectory -like "*$($pool.Name)*" }
    
    [PSCustomObject]@{
        AppPoolName       = $pool.Name
        RuntimeCLRVersion = $pool.ManagedRuntimeVersion
        TargetFramework   = if ($matchingConfig) { $matchingConfig.TargetFramework } else { "N/A" }
    }
}

If you’re running modern .NET apps (Core 3.1, 5+, etc.), they won’t show up in the app pool’s managed runtime version (it’ll say No Managed Code). Instead, use this to find their running versions:

Get-Process dotnet | ForEach-Object {
    $process = $_
    # Get the app path from the process command line
    $processDetails = Get-WmiObject Win32_Process -Filter "ProcessId = $($process.Id)"
    $appPath = Split-Path $processDetails.CommandLine -Parent
    # Get the .NET version from the dotnet executable
    $dotnetVersion = & "$($process.Path)" --version
    
    [PSCustomObject]@{
        ProcessId       = $process.Id
        ApplicationPath = $appPath
        DotNetVersion   = $dotnetVersion
    }
}

内容的提问来源于stack exchange，提问作者Tourius