How to check whether ASP.NET 4.0 registered on IIS 7.5

Question

Is there any reliable way how to check whether ASP.NET 4.0 registered on IIS 7.5 programmatically? I need to test it in the installer as prerequisite, before ASP.NET application installation start.

If ASP.NET 4.0 not registered on the IIS, later during the installation just installed application cannot be run and returns 500 internal server error (and it is too late to solve the problem). Instead, I want to show some warning (and hint how to solve the issue) before any installation steps started. But no reliable solution found yet.

AFAIK, registry entries reading sometimes may not work correctly. So now, I run aspnet_regiis.exe -lv to list versions (as suggested here) and parse the output. But even if .NET not registered correctly my test (falsely) succeeds, because the output is (contains version 4.0):

2.0.50727.0     C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll
4.0.30319.0     C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll

(Win7 32bit)

Running aspnet_regiis.exe -ir can repair it in this case.

It's similar issue as this question, but I need test it programmatically.

Do you have any ideas or experiences?

Answer 1

Using your own answer as a basis, this can also be done using the command line (with elevation):

%WINDIR%\System32\inetsrv\appcmd.exe list apppool /managedRuntimeVersion:v4.0

If anything is returned, ASP.NET 4.0 is registered. The issue with this approach is that it seems to be possible to create 4.0 application pools manually even if the filter is not installed, and then this method would not work.

---

EDIT: I have ended up running these three checks:

1. aspnet_regiis.exe -lv (should return a line containing "c:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll")
2. appcmd.exe list apppool /managedRuntimeVersion:v4.0 (should return a line containing "MgdVersion:v4.0")
3. appcmd.exe list config -section:system.webServer/isapiFilters (should return a line containing "c:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_filter.dll")

Note that I only care about 32bit versions.

If all three checks pass, it can be concluded that ASP.NET 4.0 is registered. Still not 100% false positive-proof though.

Answer 2

This is an old question, but I'm posting an answer because your question is one of the top results on google, and it's unanswered.

The registry key you are looking for is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0. If that key is present, then .Net 4 has been installed and is registered in IIS.

If you just want to check if .Net 4 is installed, you can check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full.

Answer 3

In Powershell it could be done like this:

# load the IIS-Commandlets
Import-Module WebAdministration 

# get the isapi filters currently loaded
Get-WebConfigurationProperty -Filter "/system.webServer/isapiFilters/filter" -name *

An output could look like this:

name           : ASP.Net_4.0_32bit<br/>
path           : %windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_filter.dll<br/>
enabled        : True<br/>
enableCache    : True<br/>
preCondition   : runtimeVersionv4.0,bitness32<br/>
ItemXPath      : /system.webServer/isapiFilters/filter[@name='ASP.Net_4.0_32bit']<br/>
Attributes     : {name, path, enabled, enableCache...}<br/>
ChildElements  : {}<br/>
ElementTagName : filter<br/>
Methods        :<br/>
Schema         : Microsoft.IIs.PowerShell.Framework.ConfigurationElementSchema<br/>

name           : ASP.Net_4.0_64bit<br/>
path           ........

Based on that we could write this code to check and install .NET 4 if needed:

$DotNet4Missing = $true

# lets make sure we got .net 4 correctly setup
$isapiFilters = Get-WebConfigurationProperty -Filter "/system.webServer/isapiFilters/filter" -name *

"/system.webServer/isapiFilters/filter count: {0}" -f $isapiFilters.Count
foreach ($filter in $isapiFilters)
{
    "filter.name: {0}" -f $filter.name
    if ($filter.name -eq "ASP.Net_4.0_64bit")
    {
        "-> Found .NET 4 - GREAT!"
        $DotNet4Missing = $false
    }        
}    

if ($DotNet4Missing)
{
    "Missing .NET 4 IIS integration - running aspnet_regiis.exe"

    $pinfo = New-Object System.Diagnostics.ProcessStartInfo
    $pinfo.FileName = "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe"
    $pinfo.RedirectStandardError = $true
    $pinfo.RedirectStandardOutput = $true
    $pinfo.UseShellExecute = $false
    $pinfo.Arguments = "-iru"
    $p = New-Object System.Diagnostics.Process
    $p.StartInfo = $pinfo
    $p.Start() | Out-Null
    $p.WaitForExit()
    $stdout = $p.StandardOutput.ReadToEnd()
    $stderr = $p.StandardError.ReadToEnd()

    "aspnet_regiis.exe stdout: {0}" -f $stdout
    "aspnet_regiis.exe stderr: {0}" -f $stderr
    "aspnet_regiis.exe ExitCode: {0}" -f $p.ExitCode
}

Answer 4

Summary: The problem described above occurs on non-server operating system (Win7). The .NET 4.0 is not registered on the IIS even if you install IIS before .NET 4.0 (and so .NET should be registered on IIS correctly). This causes unexpected problems during any ASP.NET application installation -- until aspnet_regiis.exe -ir is ran from the commandline. There is no problem with Win 2008 (i.e. when IIS installed before .NET 4.0 then .NET is registered correctly on IIS and everything works as expected).

So finally my colleague told me what possibly could be solution of the problem. I've verified that following solution works fine (also on Win7). ServerManager from Microsoft.Web.Administration namespace can be employed easily:

public static bool IsAspNetRegistered()
{
    using (var mgr = new ServerManager())
    {
        return mgr.ApplicationPools.Any(pool => pool.ManagedRuntimeVersion == "v4.0");
    }
}

In case of successful .NET registration on IIS, there is at least one application pool which runtime version is set to "v4.0" so this fact was used for the check.

Of course, if anybody deletes all application pools, this method can work incorrectly. But this is bit pathological situation I don't care. The main issue is to prevent that although everything is done according our installation recommendations, still not possible to install the application on the machine.