Webanwendungsprobleme (web.config-Fehler) HTTP 500.19 mit IIS7.5 und ASP.NET v2

Das macht das ganze Team verrückt. Es muss einen einfachen, falsch konfigurierten Teil von IIS oder unserem Webserver geben, aber jedes Mal, wenn wir versuchen, die ASP.NET-Webanwendung unter IIS 7.5 auszuführen, wird der folgende Fehler angezeigt ...

Hier ist der Fehler vollständig:

HTTP Error 500.19 - Internal Server Error

The requested page cannot be accessed because the related configuration  
data for the page is invalid.

`Detailed Error Information` 
Module              IIS Web Core
Notification        Unknown
Handler             Not yet determined
Error Code          0x8007000d
Config Error
Config File         \\?\E:\wwwroot\web.config
Requested URL       http://localhost:80/Default.aspx
Physical Path 
Logon Method        Not yet determined
Logon User          Not yet determined
Config Source
   -1: 
    0: 

Auf dem Computer wird Windows Server 2008 R2 ausgeführt . Wir entwickeln unsere Webanwendung mit Visual Studio 2008 .

Laut Microsoft bedeutet der Code 8007000d, dass in unserer web.config ein Syntaxfehler vorliegt - außer dass das Projekt lokal erstellt und ordnungsgemäß ausgeführt wird. Wenn Sie sich die web.config im XML-Editor ansehen, werden auch keine Syntaxfehler angezeigt. Ich gehe davon aus, dass es eine schlechte Konfiguration meinerseits sein muss ...?

Weiß jemand, wo ich weitere Informationen zu dem Fehler finden könnte? Auch in EventViewer wird nichts angezeigt :(

Ich bin mir nicht sicher, was ich sonst noch erwähnen könnte ...

Unterstützung wird sehr geschätzt. Vielen Dank!

AKTUALISIERUNG! - VERÖFFENTLICHTES WEB.CONFIG UNTEN

Ok, seit ich die ursprüngliche Frage oben gepostet habe, habe ich die genauen Zeilen in der web.config aufgespürt, die den Fehler verursacht haben.

Hier sind die Zeilen (sie erscheinen zwischen <System.webServer>Tags) ...

    <httpHandlers>
        <remove verb="*" path="*.asmx"/>
        <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
    </httpHandlers>

Hinweis: Wenn ich die Zeilen löschen zwischen dem <httpHandlers>ich noch die Störung. Ich muss buchstäblich löschen <httpHandlers>(und die Zeilen dazwischen), um den obigen Fehler nicht mehr zu bekommen.

Sobald ich dies getan habe, erhalte ich jedoch einen neuen 500.19-Fehler. Zum Glück sagt mir IIS diesmal tatsächlich, welcher Teil der web.config ein Problem verursacht ...

    <handlers>
        <remove name="WebServiceHandlerFactory-Integrated"/>
        <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory,System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
        <add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
        <add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
    </handlers>

Wenn Sie sich diese Zeilen ansehen, ist klar, dass das Problem innerhalb desselben <system.webServer>Tags weiter zum <handlers>Tag migriert ist .

Der neue Fehler ist auch expliziter und beschwert sich speziell darüber, dass das Attribut "validate" (wie in der dritten Zeile oben zu sehen) nicht erkannt wird. Wenn Sie dieses Attribut entfernen, wird beanstandet, dass dieselbe Zeile nicht das erforderliche Attribut "Name" hat. Wenn Sie dieses Attribut hinzufügen, wird ein ASP.NET- Fehler angezeigt ...

Datei oder Assembly 'System.web.Extensions, Version = 1.0.61025.0, Culture = neutral, PublicKeyToken = f2cb5667dc123a56' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die angegebene Datei wurde vom System nicht gefunden.

Offensichtlich denke ich, dass diese neuen Fehler gerade dadurch entstanden sind, dass ich die <httpHandlers>Tags an erster Stelle gelöscht habe - sie werden offensichtlich von der Anwendung benötigt -, daher bleibt die Frage: Warum sollten diese Tags überhaupt einen Fehler in IIS auslösen? ??

Muss ich etwas in IIS installieren, damit es mit ihnen funktioniert?

Nochmals vielen Dank für jede Hilfe.

WEB.CONFIG

Hier sind die lästigen Teile unseres Web.Config ... Ich hoffe, dies hilft jemandem, unser Problem zu finden!

<system.Web>

<!-- stuff cut out -->

    <httpHandlers>
        <remove verb="*" path="*.asmx"/>
        <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
        <add verb="*" path="*_AppService.axd" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
        <add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56" validate="false"/>
    </httpHandlers>
    <httpModules>
        <add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
    </httpModules>
</system.web>

<system.webServer>
    <validation validateIntegratedModeConfiguration="false"/>
    <modules>
        <add name="ScriptModule" preCondition="integratedMode" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
    </modules>
    <remove verb="*" path="*.asmx"/>
    <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
    <handlers>
        <remove name="WebServiceHandlerFactory-Integrated"/>
        <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory,System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
        <add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
        <add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
    </handlers>
</system.webServer>

Ich hatte genau diese Symptome und mein Problem war ähnlich wie bei Peter. Richten Sie ein vorhandenes Projekt auf einem neuen Server ein. Mein Projekt hat auf das IIS7 URL Rewriting-Modul verwiesen, das jedoch noch nicht auf dem neuen Server installiert war. Die Installation hat mein Problem behoben.

Sie können das Microsoft Web Platform Installer verwenden , um es zu installieren. Führen Sie es aus, wählen Sie Produkte aus , wählen Sie im linken Menü Server aus, suchen Sie URL Rewrite in der Liste und installieren Sie es.

Oder Sie können es hier herunterladen .

Nachdem ich einen Tag lang auf einer neuen Maschine damit gekämpft hatte, stieß ich auf die folgenden Links. Mir fehlten die Rewrite-Module. Das hat alles repariert.

http://forums.iis.net/t/1176834.aspx

http://learn.iis.net/page.aspx/460/using-the-url-rewrite-module/

Aha! Ich habe dieses Problem überwunden! Mein Gott, es war ein Biest für jemanden wie mich mit begrenzter IIS-Erfahrung. Ich dachte wirklich, ich würde das ganze Wochenende damit verbringen, das Problem zu beheben.

Hier ist die Lösung für alle anderen, die jemals dieses böse Problem haben.

Beachten Sie zunächst Folgendes : Wenn Sie hoffen, dass dies Ihre Lösung ist, stellen Sie sicher, dass Sie denselben Fehlercode ( 0x8007000d ) und dieselbe Konfigurationsquelle ( -1: 0 :) haben . Wenn nicht, ist dies nicht Ihre Lösung.

Das nächste, was Sie beachten sollten: AJAX ist in Ihrer web.config nicht richtig installiert!

Beheben Sie dies, indem Sie diesem Handbuch folgen:
http://www.asp.net/AJAX/documentation/live/ConfiguringASPNETAJAX.aspx

Installieren Sie dann die AJAX 1.0-Erweiterungen über diesen Link auf Ihrem Produktionsserver:

http://www.asp.net/ajax/downloads/archive/
Update : Microsoft scheint die obige Seite entfernt zu haben :(

Das ist es!

Gleiches Problem unter Server 2016, IIS 10, 500.19 Fehler. Ich habe das Redirect-Modul installiert und es hat funktioniert. Ich weiß nicht, warum dies nicht standardmäßig enthalten war.

https://www.iis.net/downloads/microsoft/url-rewrite#additionalDownloads

Um es klar auszudrücken, sieht es so aus, als würde die web.config von IIS 7 funktionieren oder funktioniert, aber das Fehlen dieses Moduls führt zu dem wirklich merkwürdigen und nicht hilfreichen Fehler. Durch Googeln gelangen Sie zu einer Microsoft-Seite, die darauf besteht, dass Ihre Website oder Ihre web.config beschädigt ist. Beides scheint nicht der Fall zu sein.

Diese nicht hilfreiche Seite finden Sie hier: https://support.microsoft.com/en-us/kb/942055

Hatte das gleiche Problem wie oben, den gleichen Fehlercode usw. Einrichten einer lokalen Website unter Windows 8. Nach langem Suchen wurde festgestellt, dass die URL-Umschreibung fehlte. Nach dem Herunterladen war alles in Ordnung. :) :)

Ich füge nur eine Antwort hinzu, weil ich stundenlang versucht habe, die gleichen Symptome (aber ein anderes Problem) zu lösen:

Eine mögliche Ursache ist eine x86-DLL in einem 64-Bit-App-Pool. Die Lösung besteht darin, 32-Bit-Apps in den Einstellungen des Anwendungspools zu aktivieren.

Für mich war es der Trick, asp.net für iis neu zu registrieren. Hoffentlich hilft das jemand anderem.

aspnet_regiis.exe -i

Zusammenfassend basierend auf den Antworten hier und anderswo:

1. Überprüfen Sie die .NET-Version des App-Pools (z. B. 2.0 vs 4.0).
2. Überprüfen Sie, ob alle IIS-referenzierten Module installiert sind. In diesem Fall handelte es sich um die AJAX-Erweiterungen (heutzutage wahrscheinlich nicht der Fall), aber das Umschreiben von URLs ist weit verbreitet.

Eine andere Möglichkeit, 500,19 Fehler ohne ersichtlichen Grund zu erhalten, besteht darin, Verzeichnisse und / oder fehlerhafte Berechtigungen zu verpassen.

Im Falle dieser Frage glaube ich, dass die Frage nach der vollständigen IIS-Version fragt. Ich nehme das wegen dieser Zeile an:

Config File         \\?\E:\wwwroot\web.config

Das IIS-Installationsprogramm erstellt normalerweise das wwwrootfür Sie und dies ist der Standardstammordner für alle Websites und der Bereitstellungspunkt für virtuelle Verzeichnisse. Es existiert immer, also kein Problem, das interessiert dich normalerweise nicht sonderlich.

Da web.config-Dateien hierarchisch sind, können Sie dort eine web.config-Masterdatei ablegen und dort einige Stammeinstellungen vornehmen, die von allen Sites geerbt werden. IIS prüft, ob diese Datei vorhanden ist, und versucht, sie zu laden.

Erster lustiger Teil:

Dieses Verzeichnis ist vorhanden, wenn Sie IIS ordnungsgemäß installiert haben. Wenn es nicht existiert, erhalten Sie einen Fehler der 500er-Klasse. Wenn Sie jedoch mit Datei- / Verzeichnisberechtigungen spielen, insbesondere mit erweiterten Berechtigungen, können Sie dem IIS-Dienstkonto versehentlich das Scannen / Lesen des Inhalts dieses Verzeichnisses verweigern . Wenn IIS nicht überprüfen kann, ob diese wwwroot \ web.config vorhanden ist oder ob sie vorhanden ist und IIS sie nicht öffnen und lesen kann - bam - Fehler der Klasse 500.

Für einen vollständigen IIS ist dies jedoch sehr unwahrscheinlich. Entwickler / Administratoren, die mit vollständigem IIS arbeiten, zögern normalerweise, damit zu spielen, wwwrootsodass es normalerweise ordnungsgemäß konfiguriert bleibt.

Allerdings auf IIS Express ..

Normalerweise funktioniert IIS Express "einfach". Oft wissen Entwickler, die IIS Express verwenden, nicht, wie sehr es intern dem echten IIS ähnelt.

Sie können leicht auf die Tatsache stoßen, dass IIS Express über eine eigene applicationHost.config-Datei verfügt und VS diese (bis zu einem gewissen Grad korrekt) für Sie erstellt und verwaltet. Diese Art von Augenöffner sagt Ihnen, dass dies nicht so einfach und sinnvoll ist. und klicken Sie, wie es zunächst scheint.

Neben dieser Konfigurationsdatei erstellt VisualStudio auch eine leere Verzeichnisstruktur unter Ihrem DocumentsOrdner. Wenn ich mich richtig erinnere, betrachtet IIS Express diese Ordner als Stammverzeichnisse Ihrer Website (s), auf denen virtuelle Verzeichnisse mit Ihrem Code bereitgestellt werden.

Später erwartet IIS Express genau wie IIS beim Start, dass diese Ordner vorhanden sind, und sucht dort nach Root-Dateien für web.config. Die Website web.config Dateien. Fast immer fehlen diese web.config-Dateien - und das ist in Ordnung, weil Sie sie nicht wollen - Sie haben Ihre ** Anwendung web.config ", sie werden mit dem Rest des Inhalts in virtuellen Verzeichnissen abgelegt.

Der zweite unterhaltsame Teil ist: IIS Express erwartet diese leeren Verzeichnisse. Sie können leer sein, aber sie müssen existieren. Wenn sie nicht vorhanden sind, wird ein Fehler der Klasse 500 angezeigt, der Sie darüber informiert, dass auf die Datei "web.config" unter diesem Pfad nicht zugegriffen werden kann.

Das erste Mal, dass ich auf dieses Problem stieß, war, als ich meine Festplatte räumte. Ich fand diesen Ordner "Dokumente \ Websites" voller Papierkorb. Ich erkannte mehrere Jahre alte Projekte, an denen ich nicht mehr arbeite, alle leer, keine einzige Datei, also löschte ich alles. Eine Woche später - bam - kann ich keine der Sites ausführen / debuggen, an denen ich gerade gearbeitet habe. Fehler war 500.19, Konfigurationsdatei kann nicht gelesen werden.

Wenn Sie also IIS Express verwenden und 500-Klassen-Fehler beim Lesen der Konfiguration sehen, überprüfen Sie die Fehlermeldung sorgfältig und lesen Sie alle genannten Pfade. Wenn Sie etwas sehen wie:

c:\users\user\documents\visual studio 2013\projects\WebProject1\WebProject1.web\web.config
c:\users\zeshan.munir\documents\visual studio 2015\projects\WebProject1\WebProject1.web\web.config
c:\users\zeshan.munir\documents\visual studio 2017\projects\WebProject1\WebProject1.web\web.config
etc..

Gehen Sie genau dorthin, wo der Fehler anzeigt, stellen Sie sicher, dass diese Ordner vorhanden sind, stellen Sie sicher, dass das IIS-Worker-Konto sie durchlaufen und lesen kann, und wenn Sie feststellen, dass etwas nicht stimmt, ist dies möglicherweise der Fall.

Übrigens. In VisualStudio gibt es in ProjectProperties / Web die Schaltfläche "Virtuelles Verzeichnis erstellen". Es macht im Wesentlichen genau das, also können Sie es zuerst versuchen, aber IIRC kann manchmal auch Konfigurationsabschnitte in der Datei applicationHost.config löschen / überschreiben / austauschen. Seien Sie also vorsichtig mit dieser Schaltfläche, wenn Sie dort benutzerdefinierte Setups haben.

In meinem Fall stimmte etwas mit der Installation des .NET Core Windows Hosting Bundle nicht.

Ich hatte das installiert und IIS nach der Installation mit ("net stop was / y" und "net start w3svc") neu gestartet, aber ich würde diesen 500.19 Fehler mit Fehlercode 0x8007000d und Config Source -1: 0: erhalten.

Ich konnte das Problem beheben, indem ich die Installation des .NET Core Windows Hosting Bundle reparierte und IIS mit den oben genannten Befehlen neu startete.

Hoffe das hilft jemandem!

Dieser schöne detaillierte Fehler ist auch 2019 noch vorhanden! Ich möchte nur hinzufügen, dass wenn Ihr web.configgültig und zugänglich ist, es höchstwahrscheinlich ein Abhängigkeitsproblem ist .

Wie vom OP erwähnt, war es ein AJAXModul und wie von anderen allgemein das RewriteModul. Halten Sie in Ihrer web.config einfach die Augen offen, auf welche Module und Bibliotheken sich Ihre Tags beziehen, da der Fehlercode 0x8007000d sich auf JEDE Abhängigkeit beziehen kann .

In meinem Fall habe ich nicht bemerkt, dass das AspNetCoreBundle fehlt und installiert werden musste! So glücklich, dass ich diesen Beitrag gefunden habe !!

Dies kann oder kann nicht verwandt sein .... Ich begann mit dem gleichen Fehler, der oben erwähnt wurde, fing an zu googeln, Änderungen vorzunehmen, neue Fehler zu bekommen, Endlosschleife.

Die Änderung, die mich durch diesen Fehler verursacht hat, hat die Feature-Delegierung im IIS-Manager im Abschnitt "Verwaltung" des Servers beeinträchtigt. Es tut mir leid, dass ich mich nicht erinnern kann, welches ich geändert habe, aber googeln könnte helfen.

Das brachte mich nach dem ersten Fehler in einen ganz neuen Strom von anderen, von denen einige völlig unsinnig waren. (Ich würde einen Fehler erhalten, wenn ich unter einem virtuellen Verzeichnis ausgeführt würde. Die Konvertierung in eine Anwendung führte zu einem anderen Fehler, usw.). Was diese Reihe von Fehlern schließlich löste, war: IIS-Manager, Anwendungspools, DefaultAppPool, 32-Bit-Anwendungen aktivieren = True

Ich hatte diese App auf einer 32-Bit-Windows XP-Box gestartet und führe sie jetzt auf einer 64-Bit-Windows 7-Box aus.

Hoffentlich hilft das jemand anderem.

Mein IIS 7.5 versteht das Tag in web.config nicht. In VS 2010 wird dieses Tag ebenfalls unterstrichen. Überprüfen Sie Ihre Konfigurationsdatei genau, um alle unterstrichenen Tags zu finden. Ich habe es in den Kommentar eingefügt und der Fehler verschwindet.

Kommentieren Sie die folgenden Zeilen in der Datei web.config.

<modules>
    <!--<add name="ScriptModule" preCondition="integratedMode" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>-->
</modules>

<handlers>
    <remove name="WebServiceHandlerFactory-ISAPI-2.0"/>
    <!--<add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    <add name="ScriptResource" verb="GET" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>-->
</handlers>

Das wird funktionieren.

Ich hatte den gleichen Fehler. Ich hatte eine IIS-Site mit .net Framework Version 2.0, aber meine App benötigte 4.0. Ich habe die Version geändert und es hat funktioniert.

Posting nur zur Erinnerung, wenn jemand das gleiche Problem hat.

Stellen Sie sicher, dass alle Ihre IIS-Funktionen ordnungsgemäß aktiviert sind.

• Öffnen Sie die Windows-Funktionen (Aktivieren oder deaktivieren Sie die Windows-Funktionen).

• Scrollen Sie nach unten zu Internetinformationsdienste

• Öffnen Sie die Dropdown-Liste World Wide Web plus

• Öffnen Sie das Dropdown-Feld Anwendungsentwicklungsfunktionen plus
• Aktivieren Sie alle nachfolgenden Kontrollkästchen manuell und klicken Sie dann auf OK

Die folgende Konfiguration war die Ursache für mein Problem:

    <rewrite>
      <rules>
        <clear />
        <rule name="Redirect to HTTPS" stopProcessing="true">
          <match url="(.*)" />
          <conditions>
            <add input="{HTTP_HOST}" pattern="^.*spvitals\.com$" />
            <add input="{HTTPS}" pattern="off" ignoreCase="true" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" appendQueryString="false" />
        </rule>
      </rules>
    </rewrite>

Hinweis: Ich habe diesen Abschnitt für lokale Tests entfernt, da er in Azure einwandfrei funktioniert.

Ich hatte das gleiche Problem in Windows 7.

Die Lösung bestand darin, zu den Grundeinstellungen> Verbindung als> bestimmter Benutzer zu wechseln und sich als Benutzer anzumelden, anstatt als Standard-Pass-Through.

Dies hat das Problem für mich behoben.

Windows 7

Versuche dies,

Führen Sie cmd als Admin aus.

Alle kristallisieren.

start /w pkgmgr.exe /uu:IIS-WebServerRole;WAS-WindowsActivationService

Installieren Sie es neu und normalerweise funktioniert es

Alain

Ich habe diesen Fehler erhalten, indem ich das <customErrors>Tag innerhalb von platziert habe, <system.webServer>anstatt <system.web>wo es hingehört. Es gab ein kleines Kringeln unter dem <customErrors>Etikett, aber ich bemerkte es nicht sofort.

Ähnlich wie bei der Top-Antwort erhielten wir diese unglaublich wenig hilfreiche Ausnahme aufgrund eines fehlenden IIS CORS-Moduls. Es war genau der gleiche Fehler mit Fehlercode (0x8007000d) und Konfigurationsquelle (-1: 0 :), aber die Installation des URL-Umschreibemoduls hat ihn nicht behoben.

Wir hatten kürzlich die web.config aktualisiert, um CORS für einige Entwickler zu aktivieren, die es benötigten, aber nicht erwartet, dass alle Entwickler das IIS CORS-Modul installieren müssen. Leider sieht es so aus, als wäre es erforderlich.

Installieren Sie das IIS CORS-Modul von hier aus , um das Problem zu beheben .

Wenn Sie die Anwendung asp.net.core bereitstellen, müssen Sie auch das .net Core-Hosting-Bundle installieren. https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/index?view=aspnetcore-3.0#install-the-net-core-hosting-bundle