Как проверить, зарегистрирован ли ASP.NET 4.0 на IIS 7.5

Question

Есть ли надежный способ как программно проверить, зарегистрирован ли ASP.NET 4.0 в IIS 7.5? Мне нужно проверить его в установщике как обязательное условие перед началом установки приложения ASP.NET.

Если ASP.NET 4.0 не зарегистрирован в IIS, позднее во время установки только что установленное приложение не может быть запущено и возвращает 500 внутреннюю ошибку сервера (и уже слишком поздно для решения проблемы). Вместо этого я хочу показать некоторые предупреждения (и подсказку, как решить проблему) перед началом любых шагов установки. Но надежного решения пока не найдено.

AFAIK, чтение записей реестра иногда может работать некорректно. Итак, теперь я запускаю aspnet_regiis.exe -lv для вывода списка версий (как предложено здесь ) и анализирую вывод. Но даже если .NET не зарегистрирован правильно, мой тест (ложно) будет успешным , потому что вывод (содержит версию 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)

Запуск aspnet_regiis.exe -ir может исправить это в этом случае.

Эта проблема похожа на вопрос , но мне нужно протестировать ее программно .

У вас есть идеи или опыт?

Answer 1

Используя собственный ответ в качестве основы, это также можно сделать с помощью командной строки (с повышением прав):

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

Если что-то возвращается, ASP.NET 4.0 регистрируется. Проблема этого подхода заключается в том, что представляется возможным создать пулы приложений 4.0 вручную, даже если фильтр не установлен, и тогда этот метод не будет работать.

---

EDIT: Я закончил тем, что управлял этими тремя проверками:

1. aspnet_regiis.exe -lv (должна возвращать строку, содержащую «c: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ aspnet_isapi.dll»)
2. appcmd.exe list apppool /managedRuntimeVersion:v4.0 (должна возвращать строку, содержащую «MgdVersion: v4.0»)
3. appcmd.exe list config -section:system.webServer/isapiFilters (должна возвращать строку, содержащую «c: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ aspnet_filter.dll»)

Обратите внимание, что меня интересуют только 32-битные версии.

Если все три проверки пройдены, можно сделать вывод, что ASP.NET 4.0 зарегистрирован. Тем не менее, не на 100% ложно-положительное доказательство.

Answer 2

Это старый вопрос, но я публикую ответ, потому что ваш вопрос - один из самых популярных результатов в Google, и он не получил ответа.

Ключ реестра, который вы ищете, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0.Если этот ключ присутствует, то .Net 4 был установлен и зарегистрирован в IIS.

Если вы просто хотите проверить, установлен ли .Net 4, вы можете проверить HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full.

Answer 3

В Powershell это можно сделать так:

# load the IIS-Commandlets
Import-Module WebAdministration 

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

Вывод может выглядеть так:

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           ........

Исходя из этого, мы могли бы написать этот код для проверки и установки.NET 4 при необходимости:

$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

Описание: описанная выше проблема возникает в несерверной операционной системе (Win7). .NET 4.0 не регистрируется в IIS, даже если вы устанавливаете IIS до .NET 4.0 (и поэтому .NET должен быть правильно зарегистрирован в IIS). Это вызывает непредвиденные проблемы во время любой установки приложения ASP.NET - до запуска aspnet_regiis.exe -ir из командной строки. С Win 2008 проблем нет (т. Е. Когда IIS установлен до .NET 4.0, тогда .NET правильно зарегистрирован на IIS и все работает как положено).

Итак, наконец, мой коллега сказал мне, что может быть решением проблемы. Я убедился, что следующее решение работает хорошо (также на Win7). ServerManager из Microsoft.Web.Administration пространства имен можно легко использовать:

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

В случае успешной регистрации .NET в IIS существует по крайней мере один пул приложений, версия времени выполнения которого установлена ​​на «v4.0», поэтому этот факт был использован для проверки.

Конечно, если кто-нибудь удалит все пулы приложений, этот метод может работать некорректно. Но это немного патологическая ситуация, мне все равно. Основная проблема заключается в том, чтобы предотвратить выполнение программы в соответствии с нашими рекомендациями по установке, однако по-прежнему невозможно установить приложение на компьютер.