Retting av feil 500.19: Konfigurasjonsside ugyldig under distribusjon av Blazor-prosjektet på IIS

Forstå konfigurasjonsfeilen i IIS-distribusjon

Å distribuere et Blazor-prosjekt til IIS kan være en jevn prosess, men noen ganger oppstår feil som kan være vanskelig å diagnostisere. Et vanlig problem utviklere møter er Feil 500.19, som vanligvis indikerer et problem med konfigurasjonssiden. Denne feilen hindrer programmet i å starte på riktig måte.

Feil 500.19 peker vanligvis på en feilkonfigurasjon i web.config fil, men selv etter å ha gjennomgått den, kan feilen vedvare. Denne situasjonen kan være frustrerende når ingenting vises feil i selve konfigurasjonen. Utviklere møter ofte dette når de prøver å distribuere Blazor-applikasjoner, spesielt når feilmeldingen virker vag.

Utover konfigurasjonsproblemer kan det være underliggende tillatelsesproblemer eller manglende komponenter på serveren. For eksempel kan problemer med IIS-tillatelser eller et feilkonfigurert miljø også utløse denne feilen. Å sikre at alle nødvendige moduler og tillatelser er på plass er avgjørende for vellykket distribusjon.

I denne artikkelen vil vi utforske trinnene du kan ta for å feilsøke Feil 500.19 og løse konfigurasjonsproblemer. Ved å undersøke web.config-filen, bekrefte tillatelser og sjekke servermiljøet, kan du finne årsaken til problemet.

Forstå Blazor Deployment Error Scripts

Det første skriptet som tilbys er designet for å håndtere potensielle feilkonfigurasjoner i web.config fil, som ofte forårsaker 500.19-feilen i IIS. Den kritiske komponenten her er `` handler, som integrerer Blazor-appen med IIS-miljøet. Denne taggen dirigerer IIS til riktig applikasjonsbane og sikrer at appen kjører med AspNetCoreModuleV2 for igangværende hosting. Hvis denne modulen ikke er riktig satt eller konfigurert, vil ikke Blazor-applikasjonen starte, noe som fører til 500.19-feilen. Prosessbanen og loggingsparameterne må også være nøyaktige, siden de hjelper til med å finne den kjørbare filen og administrere loggutdata.

I den andre løsningen adresserer vi mulige tillatelsesproblemer ved å bruke PowerShell. De icacls kommandoen gir nødvendige tillatelser til IIS_IUSRS-gruppen, som er avgjørende for at Blazor-appen skal få tilgang til katalogene og filene. Uten disse tillatelsene kan serveren blokkere programmet fra å kjøre, noe som fører til feil som 500.19. Ved å bruke PowerShell kan du raskt sette disse tillatelsene i et batch-skript, og sikre at alle nødvendige brukere og grupper har lese- og skrivetilgang til appens mappe.

Den tredje løsningen fokuserer på feilsøking ved å aktivere stdout-logging i Blazor-konfigurasjonen. Aktiverer stdoutLogEnabled hjelper med å fange opp kjøretidsfeil ved å logge dem til en spesifisert fil. Denne metoden er kritisk under distribusjon, siden mange feil som ikke er synlige gjennom nettleseren eller IIS-feilloggene kan fanges opp her. Ved å sjekke loggene i mappen `./logs/stdout`, kan utviklere spore opp spesifikke problemer, enten de er relatert til applikasjonskode eller miljøkonfigurasjonsproblemer.

Til slutt sjekker det fjerde skriptet om AspNetCoreModuleV2 er installert i IIS. Dette gjøres ved å bruke PowerShell med Get-WebGlobalModule kommando, som viser alle globale moduler installert på serveren. Hvis modulen mangler, en påfølgende kommando, Installer-Windows-funksjon, installerer de nødvendige IIS-komponentene. Dette sikrer at Blazor-applikasjonen har alle nødvendige avhengigheter for å kjøre riktig. Uten disse modulene kan ikke Blazor-apper fungere under IIS, noe som fører til konfigurasjonsfeil som 500.19. Enhetstestingsskriptet sikrer at katalogtillatelser og IIS-modulinnstillinger brukes riktig, og gir et ekstra lag med validering for distribusjonsprosessen.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="" verb="" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath=".\BlazorApp2.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
    </system.webServer>
  </location>
</configuration>
<!--Ensure the right handler is mapped, and the processPath is correct.-->

# PowerShell script to set proper permissions for the application directory
param (
  [string]$path = "C:\inetpub\wwwroot\BlazorApp"
)
# Grant read and write permissions to IIS_IUSRS
icacls $path /grant "IIS_IUSRS:(OI)(CI)RX"
icacls $path /grant "IIS_IUSRS:(OI)(CI)(F)"
Write-Host "Permissions set successfully on $path"
# Make sure this script is run with administrative privileges.

<configuration>
  <system.webServer>
    <aspNetCore processPath=".\BlazorApp2.exe" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
  </system.webServer>
</configuration>
# After enabling logging, ensure that the "logs" folder exists in the application directory.
# Check the logs for further information on what's causing the deployment issue.
# Disable stdout logging in production to avoid performance issues.

# PowerShell script to check if IIS modules are installed
Import-Module WebAdministration
$modules = Get-WebGlobalModule | Where-Object {$_.Name -eq "AspNetCoreModuleV2"}
if ($modules -eq $null) {
  Write-Host "AspNetCoreModuleV2 is missing. Installing the module..."
  Install-WindowsFeature -Name Web-Asp-Net45
} else {
  Write-Host "AspNetCoreModuleV2 is already installed."
}

using NUnit.Framework;
namespace BlazorApp.Tests
{
  public class DeploymentTests
  {
    [Test]
    public void TestPermissionsAreSetCorrectly()
    {
      var directory = "C:\\inetpub\\wwwroot\\BlazorApp";
      var permissions = new System.Security.AccessControl.DirectorySecurity(directory, System.Security.AccessControl.AccessControlSections.All);
      Assert.IsTrue(permissions.AreAccessRulesProtected == false, "Permissions are incorrect!");
    }
  }
}
# This unit test validates whether the directory permissions are correctly set.

Utforsker IIS-konfigurasjon for Blazor-implementeringer

Når du distribuerer et Blazor-prosjekt på IIS, er et vanlig problem feil konfigurasjon av IIS-moduler, spesielt AspNetCoreModuleV2. Denne modulen er ansvarlig for å være vert for .NET Core-applikasjoner i IIS og må installeres på riktig måte. Hvis den mangler, kan den forårsake feil som 500.19. Å sikre at riktig versjon av denne modulen er aktivert er avgjørende for at Blazor-appen skal fungere skikkelig. I tillegg kan det å verifisere at vertsmodellen er satt til "inprocess" eller "outofprocess" være nøkkelen til å løse disse problemene.

En annen faktor som kan føre til 500.19-feilen er mangelen på nødvendige komponenter i målmiljøet. For eksempel kan det føre til konfigurasjonsproblemer å kjøre en Blazor-app på en server som ikke har den riktige .NET runtime-versjonen installert. Å sikre at serveren har samme kjøretid som Blazor-appen er avgjørende for en vellykket distribusjon. I tillegg bør administratorer også bekrefte at riktig applikasjonspool brukes for nettstedet i IIS, spesielt en som er konfigurert til å bruke .NET Core.

I tillegg til konfigurasjonsproblemer, spiller mappetillatelser en viktig rolle i distribusjonsprosessen. Selv om du har gitt tillatelser til IIS_IUSRS gruppe, kan ytterligere sikkerhetsregler hindre tilgang til bestemte filer eller kataloger. Å verifisere og endre disse tillatelsene gjennom verktøy som PowerShell eller IIS Manager sikrer at Blazor-appen har tilstrekkelig tilgang til de nødvendige filene for kjøretidsoperasjoner. Kombinasjonen av moduloppsett, kjøretidskompatibilitet og tillatelser er avgjørende for å feilsøke denne feilen.