Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
av Tom Dykstra
Den här självstudieserien visar hur du distribuerar (publicerar) en ASP.NET webbapp till Azure App Service Web Apps eller till en tredjepartsvärdleverantör med hjälp av Visual Studio 2012 eller Visual Studio 2010. Information om serien finns i den första självstudien i serien.
På den här sidan beskrivs några vanliga problem som kan uppstå när du distribuerar en ASP.NET webbapp med hjälp av Visual Studio. För var och en tillhandahålls en eller flera möjliga orsaker och motsvarande lösningar.
De scenarier som visas gäller för både Azure- och tredjepartsvärdleverantörer. Mer information om hur du felsöker webbappar i Azure App Service finns i följande resurser:
- Felsöka en webbapp i Azure App Service med Visual Studio
- Övervaka Web Apps i Azure App Service
- Meddelande om lanseringen av Windows Azure SDK 2.0 för .NET (ScottGus blogg visar hur du hämtar diagnostikloggar i Visual Studio)
Serverfel i "/"-programmet – Aktuella anpassade felinställningar förhindrar att information om felet visas via fjärranslutning
Scenario
När du har distribuerat en webbplats till en fjärrvärd får du ett felmeddelande som nämner inställningen customErrors i filen Web.config men som inte anger vad den verkliga orsaken till felet var:
Server Error in '/' Application.
Runtime Error
Description: An application error occurred on the server. The current custom error settings
for this application prevent the details of the application error from being viewed remotely
(for security reasons). It could, however, be viewed by browsers running on the local server
machine.
Details: To enable the details of this specific error message to be viewable on remote machines,
please create a <customErrors> tag within a "web.config" configuration file located in the
root directory of the current web application. This <customErrors> tag should then have its
"mode" attribute set to "Off".
Möjlig orsak och lösning
Som standard visar ASP.NET endast detaljerad felinformation när webbprogrammet körs på den lokala datorn. I allmänhet vill du inte visa detaljerad felinformation när webbprogrammet är offentligt tillgängligt via Internet, eftersom hackare kanske kan använda den här informationen för att hitta sårbarheter i programmet. Ibland, när du distribuerar en webbplats eller uppdateringar till en webbplats, går något fel och du behöver få det faktiska felmeddelandet.
Om du vill att programmet ska visa detaljerade felmeddelanden när det körs på fjärrvärden redigerar du Web.config-filen för att ställa in customErrors-läget av, distribuera om programmet och köra programmet igen:
Om programmet Web.config filen har ett customErrors-element i elementet system.web ändrar du modeattributet till "off". Annars lägger du till ett customErrors-element i system.web-elementet med modeattributet inställt på "off", som du ser i följande exempel:
<configuration> <system.web> <customErrors mode="off"/> </system.web> </configuration>Distribuera programmet.
Kör programmet och upprepa det du gjorde tidigare som orsakade felet. Nu kan du se vad det faktiska felmeddelandet är.
När du har löst felet återställer du den ursprungliga customErrors-inställningen och distribuerar om programmet.
Det går inte att skapa/skuggkopia "ContosoUniversity" när filen redan finns.
Scenario
När du försöker köra ett projekt i Visual Studio får du en felsida med ett meddelande som liknar följande exempel:
Serverfel i "/"-programmet. Det går inte att skapa/skuggkopia "ContosoUniversity" när filen redan finns.
Möjlig orsak och lösning
Vänta en minut och uppdatera webbläsaren eller kompilera om webbplatsen och försök köra den igen.
Åtkomst nekas på en webbsida som använder SQL Server Compact
Scenario
När du distribuerar en plats som använder SQL Server Compact och kör en sida på den distribuerade platsen som kommer åt databasen visas följande felmeddelande:
Åtkomst avslås. (Undantag från HRESULT: 0x80070005 (E_ACCESSDENIED))
Möjlig orsak och lösning
NETWORK SERVICE-kontot på servern måste kunna läsa inbyggda binärfiler för SQL Service Compact som finns i mappen bin\amd64 eller bin\x86 , men det har inte läsbehörighet för dessa mappar. Ange läsbehörighet för NETWORK SERVICE i mappen bin , se till att utöka behörigheterna till undermappar.
Det går inte att läsa konfigurationsfilen på grund av otillräcklig behörighet
Scenario
När du klickar på visual studiopubliceringsknappen för att distribuera ett program till IIS på den lokala datorn misslyckas publiceringen och fönstret Utdata visar ett felmeddelande som liknar detta:
Ett fel uppstod när IIS-konfigurationsfilen "MACHINE/REDIRECTION" lästes. Identiteten som utförde den här åtgärden var ... Fel: Det går inte att läsa konfigurationsfilen på grund av otillräcklig behörighet.
Möjlig orsak och lösning
Om du vill använda publicera med ett klick till IIS på den lokala datorn måste du köra Visual Studio med administratörsbehörighet. Stäng Visual Studio och starta om det med administratörsbehörighet.
Det gick inte att ansluta till måldatorn ... Använda den angivna processen
Scenario
När du klickar på knappen Publicera i Visual Studio för att distribuera ett program misslyckas publiceringen och fönstret Utdata visar ett felmeddelande som liknar detta:
Web deployment task failed.(Could not connect to the destination computer ("<server URL>") using the specified process
("The Web Management Service"). This can happen if a proxy server is interrupting communication with the destination server.
Disable the proxy server and try again.) ... The remote server returned an error: (502) Bad Gateway.
Möjlig orsak och lösning
En proxyserver avbryter kommunikationen med målservern. På Kontrollpanelen i Windows eller i Internet Explorer väljer du Internetalternativ och väljer fliken Anslutningar . I dialogrutan Internetegenskaper klickar du på LAN-inställningar. I dialogrutan Inställningar för lokalt nätverk (LAN) avmarkerar du kryssrutan Identifiera inställningar automatiskt . Klicka sedan på publiceringsknappen igen.
Om problemet kvarstår kontaktar du systemadministratören för att avgöra vad som kan göras med proxy- eller brandväggsinställningar. Problemet uppstår eftersom Web Deploy använder en port som inte är standard för distribution av webbhanteringstjänsten (8172). för andra anslutningar använder Web Deploy port 80. När du distribuerar till en tredjepartsvärdleverantör använder du vanligtvis webbhanteringstjänsten.
Standardprogrampoolen för .NET 4.0 finns inte
Scenario
När du distribuerar ett program som kräver .NET Framework 4 visas följande felmeddelande:
Standardprogrampoolen för .NET 4.0 finns inte eller så gick det inte att lägga till programmet. Kontrollera att ASP.NET 4.0 är installerat på den här datorn.
Möjlig orsak och lösning
ASP.NET 4 är inte installerat i IIS. Om den server som du distribuerar till är utvecklingsdatorn och har Visual Studio 2010 installerat på den, är ASP.NET 4 installerad på datorn men kanske inte installeras i IIS. På den server som du distribuerar till öppnar du en upphöjd kommandotolk och installerar ASP.NET 4 i IIS genom att köra följande kommandon:
cd %windir%\Microsoft.NET\Framework\v4.0.30319
aspnet_regiis.exe –iru
Du kan också behöva ange .NET Framework-versionen av standardprogrampoolen manuellt. Mer information finns i guiden Distribuera på IIS som en testmiljö i den här serien.
Initieringssträngens format överensstämmer inte med specifikationen från index 0.
Scenario
När du har distribuerat ett program med ett klick på publicera visas följande felmeddelande när du kör en sida som kommer åt databasen:
Initieringssträngens format överensstämmer inte med specifikationen från index 0.
Möjlig orsak och lösning
Öppna filenWeb.config på den distribuerade webbplatsen och kontrollera om anslutningssträngvärdena börjar med $(ReplaceableToken_, som i följande exempel:
<connectionStrings>
<add name="DefaultConnection" connectionString="$(ReplaceableToken_DefaultConnection-Web.config Connection String_0)" providerName="System.Data.SqlServerCe.4.0" />
<add name="SchoolContext" connectionString="$(ReplaceableToken_SchoolContext-Web.config Connection String_0)" providerName="System.Data.SqlServerCe.4.0" />
</connectionStrings>
Om anslutningssträngarna ser ut som i det här exemplet redigerar du projektfilen och lägger till följande egenskap i PropertyGroup-elementet som gäller för alla byggkonfigurationer:
<AutoParameterizationWebConfigConnectionStrings>False</AutoParameterizationWebConfigConnectionStrings>
Distribuera sedan programmet igen.
HTTP 500 Internt serverfel
Scenario
När du kör den distribuerade webbplatsen visas följande felmeddelande utan specifik information som anger orsaken till felet:
HTTP-fel 500 – Internt serverfel.
Möjlig orsak och lösning
Det finns många orsaker till 500-fel, men en möjlig orsak om du följer de här självstudierna är att du placerar ett XML-element på fel plats i någon av de Web.config transformeringsfilerna. Du skulle till exempel få det här felet om du placerar transformeringen som infogar ett <platselement> under <system.web> i stället för direkt under <konfigurationen>. Du kan använda förhandsgranskningsfunktionen för Web.config-transformationer för att kontrollera att de fungerar som avsett. Lösningen om du hittar en transformering som kodades felaktigt är att korrigera transformeringsfilen och distribuera om. Om ett fel inte är uppenbart kan du prova att kommentera ut omvandlingar och omarbeta för att se vilken som orsakar 500-felet.
HTTP 500.21 Internserverfel
Scenario
När du kör den distribuerade webbplatsen visas följande felmeddelande:
HTTP-fel 500.21 – Internt serverfel. Hanteraren "PageHandlerFactory-Integrated" har en felaktig modul "ManagedPipelineHandler" i sin modullista.
Möjlig orsak och lösning
Den webbplats som du har distribuerat riktar sig mot ASP.NET 4, men ASP.NET 4 är inte registrerad i IIS på servern. Öppna en upphöjd kommandotolk på servern och registrera ASP.NET 4 genom att köra följande kommandon:
cd %windir%\Microsoft.NET\Framework\v4.0.30319
aspnet_regiis.exe –iru
Du kan också behöva ange .NET Framework-versionen av standardprogrampoolen manuellt. För mer information, se självstudien "Distribuera till IIS som en testmiljö" i den här serien.
Det gick inte att öppna SQL Server Express Database i App_Data
Scenario
Du har uppdaterat Web.config filanslutningssträngen så att den pekar på en SQL Server Express-databas som en .mdf fil i mappen App_Data och första gången du kör programmet visas följande felmeddelande:
System.Data.SqlClient.SqlException: Det går inte att öppna databasen "DatabaseName" som begärdes vid inloggningen. Inloggningen misslyckades.
Möjlig orsak och lösning
Namnet på filen .mdf kan inte matcha namnet på en SQL Server Express-databas som någonsin har funnits på datorn, även om du har tagit bort .mdf-filen för den tidigare befintliga databasen. Ändra namnet på den .mdf filen till ett namn som aldrig har använts som databasnamn och ändra Web.config-filen så att det nya namnet används. Du kan också använda SQL Server Management Studio Express för att ta bort tidigare befintliga SQL Server Express-databaser.
Det går inte att kontrollera modellkompatibiliteten
Scenario
Du uppdaterade Web.config filanslutningssträngen så att den pekar på en ny SQL Server Express-databas och första gången du kör programmet visas följande felmeddelande:
Det går inte att kontrollera modellkompatibiliteten eftersom databasen inte innehåller modellmetadata. Se till att IncludeMetadataConvention har lagts till i DbModelBuilder-konventionerna.
Möjlig orsak och lösning
Om databasnamnet som du lade till i Web.config-filen någonsin användes tidigare på datorn kanske en databas redan finns med några tabeller i den. Välj ett nytt namn som inte har använts på datorn tidigare och ändra Web.config-filen så att den använder det nya databasnamnet. Du kan också använda SQL Server Express Utility eller SQL Server Management Studio Express för att ta bort den befintliga databasen.
SQL-fel när ett skript försöker skapa användare eller roller
Scenario
Du använder databasdistribution som konfigurerats på fliken Paket/Publicera SQL , SQL-skript som körs under distributionen inkluderar kommandona Skapa användare eller Skapa roll och skriptkörningen misslyckas när dessa kommandon körs. Du kan se mer detaljerade meddelanden, till exempel följande:
The approximate location of the error was between lines '1' and '3' of the script.
The verbose log may have more information about the error. The command started with:
CREATE USER [user2] FOR LOGIN [user2] WITH DEFAULT
Error: User does not have permission to perform this action.
Om det här felet uppstår när du har konfigurerat databasdistributionen i guiden Publicera webb i stället för fliken Paket/Publicera SQL skapar du en tråd i forumet Konfiguration och distribution och lösningen läggs till på den här felsökningssidan.
Möjlig orsak och lösning
Det användarkonto som du använder för att utföra distributionen har inte behörighet att skapa användare eller roller. Värdföretaget kan till exempel tilldela db_datareader, db_datawriter och db_ddladmin roller till det användarkonto som det konfigurerar åt dig. Dessa är tillräckliga för att skapa de flesta databasobjekt, men inte för att skapa användare eller roller. Ett sätt att undvika felet är att undanta användare och roller från databasdistribution. Du kan göra detta genom att redigera PreSource-elementet för databasens automatiskt genererade skript så att det innehåller följande attribut:
CopyAllUsers=false, CopyAllRoles=false
Information om hur du redigerar PreSource-elementet i projektfilen finns i Så här redigerar du distributionsinställningar i projektfilen. Om användarna eller rollerna i utvecklingsdatabasen måste finnas i måldatabasen kontaktar du värdleverantören för hjälp.
Sql Server-timeoutfel vid körning av anpassade skript under distribution
Scenario
Du har angett anpassade SQL-skript som ska köras under distributionen, och när Web Deploy kör dem överskrider de tidsgränsen.
Möjlig orsak och lösning
Om du kör flera skript som har olika transaktionslägen kan det orsaka timeout-fel. Som standard körs automatiskt genererade skript i en transaktion, men anpassade skript gör det inte. Om du väljer alternativet Hämta data och/eller schema från en befintlig databas på fliken Paket/Publicera SQL , och om du lägger till ett anpassat SQL-skript måste du ändra transaktionsinställningarna för vissa skript så att alla skript använder samma transaktionsinställningar. Mer information finns i Så här distribuerar du en databas med ett webbprogramprojekt.
Om du har konfigurerat transaktionsinställningar så att alla är samma men ändå får det här felet är en möjlig lösning att köra skripten separat. I rutnätet Databasskript på fliken Paket/Publicera SQL avmarkerar du kryssrutan Inkludera för skriptet som orsakar timeout-felet och publicerar sedan projektet. Gå sedan tillbaka till rutnätet Databasskript , markera kryssrutan Inkludera i skriptet och avmarkera kryssrutorna Inkludera för de andra skripten. Publicera sedan projektet igen. Den här gången när du publicerar körs endast det valda anpassade skriptet.
Stream-data för webbplatsmanifestet är ännu inte tillgängligt
Scenario
När du installerar ett paket med hjälp av deploy.cmd-filen med alternativet t (test) visas följande felmeddelande:
Fel: Dataströmdata för "sitemanifest/dbFullSql[@path='C:\TEMP\AdventureWorksGrant.sql']/sqlScript' är ännu inte tillgängliga.
Möjlig orsak och lösning
Felmeddelandet innebär att kommandot inte kan skapa en testrapport. Kommandot kan dock köras om du använder alternativet y (faktisk installation). Meddelandet anger bara att det är problem med att köra kommandot i testläge.
Det här programmet kräver ManagedRuntimeVersion v4.0
Scenario
När du försöker distribuera visas följande felmeddelande:
Den programpool som du försöker använda har egenskapen "managedRuntimeVersion" inställd på "v2.0". Det här programmet kräver "v4.0".
Möjlig orsak och lösning
ASP.NET 4 är inte installerat i IIS. Om den server som du distribuerar till är utvecklingsdatorn och har Visual Studio 2010 installerat på den, är ASP.NET 4 installerad på datorn men kanske inte installeras i IIS. På den server som du distribuerar till öppnar du en upphöjd kommandotolk och installerar ASP.NET 4 i IIS genom att köra följande kommandon:
cd %windir%\Microsoft.NET\Framework\v4.0.30319
aspnet_regiis.exe –i
Det går inte att casta Microsoft.Web.Deployment.DeploymentProviderOptions
Scenario
När du distribuerar ett paket visas följande felmeddelande:
Det går inte att omvandla objekt av typen "Microsoft.Web.Deployment.DeploymentProviderOptions" till "Microsoft.Web.Deployment.DeploymentProviderOptions".
Möjlig orsak och lösning
Du försöker distribuera från IIS Manager med hjälp av webbdistributionsgränssnittet 1.1 till en server som har Web Deploy 2.0 installerat. Om du använder fjärradministrationsverktyget för IIS för att distribuera genom att importera ett paket markerar du dialogrutan Nya tillgängliga funktioner när du upprättar anslutningen. (Den här dialogrutan kanske bara visas en gång när anslutningen först upprättas. Om du vill rensa anslutningen och börja om stänger du IIS-hanteraren och startar den igen genom att ange inetmgr /reset i kommandotolken.) Om en av funktionerna i listan är användargränssnittet för webbdistribution och har ett versionsnummer som är lägre än 8, kan den server som du distribuerar till ha både 1.1- och 2.0-versioner av Web Deploy installerade. Om du vill distribuera från en klient som har 2.0 installerat får servern bara ha Web Deploy 2.0 installerat. Du måste kontakta din värdleverantör för att lösa problemet.
Det går inte att läsa in de inbyggda komponenterna i SQL Server Compact
Scenario
När du kör den distribuerade webbplatsen visas följande felmeddelande:
Det går inte att läsa in de inbyggda komponenterna i SQL Server Compact som motsvarar ADO.NET-providern av version 8482. Installera rätt version av SQL Server Compact. Mer information finns i KB-artikeln 974247.
Möjlig orsak och lösning
Den distribuerade platsen har inte amd64- och x86-undermappar med inbyggda sammansättningar under applikationens bin-mapp. På en dator som har SQL Server Compact installerat finns de inbyggda sammansättningarna i C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Private. Det bästa sättet att få rätt filer till rätt mappar i ett Visual Studio-projekt är att installera NuGet SqlServerCompact-paketet. Paketinstallationen lägger till ett skript efter bygget för att kopiera de inbyggda sammansättningarna till amd64 och x86. För att dessa ska kunna distribueras måste du dock inkludera dem manuellt i projektet. Mer information finns i självstudien Distribuera SQL Server Compact .
Felet "Sökvägen är inte giltig" efter att en Entity Framework Code First-applikation har distribuerats
Scenario
Du distribuerar ett program som använder Entity Framework Code First Migrations och en DBMS, till exempel SQL Server Compact, som lagrar databasen i en fil i mappen App_Data. Du har konfigurerat Code First Migrations för att skapa databasen efter din första distribution. När du kör programmet får du ett felmeddelande som i följande exempel:
Sökvägen är inte giltig. Kontrollera databasens katalog. [Path = c:\inetpub\wwwroot\App_Data\DatabaseName.sdf ]
Möjlig orsak och lösning
Code First försöker skapa databasen men mappen App_Data finns inte. Antingen hade du inga filer i mappen App_Data när du distribuerade eller så valde du Exkludera App_Data på fliken Paket/Publicera webb i fönstret Projektegenskaper. Distributionsprocessen skapar inte en mapp på servern om det inte finns några filer i mappen som ska kopieras till servern. Om du redan har konfigurerat databasen på platsen kommer distributionsprocessen att ta bort filerna och själva App_Data mappen om du valde Ta bort ytterligare filer på målet i publiceringsprofilen. Lös problemet genom att placera en platshållarfil, till exempel en .txt fil i mappen App_Data , kontrollera att du inte har Exkludera App_Data markerat och distribuera om.
"COM-objekt som har separerats från dess underliggande RCW kan inte användas."
Scenario
Du har framgångsrikt använt enkel publicering för att distribuera din applikation, och sedan börjar du få det här felet:
Webbdistributionsuppgiften misslyckades. (Det gick inte att slutföra begäran till fjärragentens URL.<https://serverurl.com/msdeploy.axd?site=sitename>)
Det gick inte att slutföra begäran till fjärragentens URL<https://url/msdeploy.axd?site=sitename>.
Begäran avbröts: Begäran avbokades.
COM-objekt som har separerats från dess underliggande RCW kan inte användas.
Möjlig orsak och lösning
Att stänga och starta om Visual Studio är vanligtvis allt som krävs för att lösa det här felet.
Distributionen misslyckas eftersom användaruppgifter som används för publicering inte har behörighet till setACL.
Scenario
Publiceringen misslyckas med ett fel som anger att du inte har behörighet att ange mappbehörigheter (användarkontot du använder har inte setACL-behörighet).
Möjlig orsak och lösning
Som standard anger Visual Studio läsbehörigheter på webbplatsens rotmapp och skrivbehörigheter för App_Data-mappen. Om du vet att standardbehörigheterna för webbplatsmappar är korrekta och inte behöver anges inaktiverar du det här beteendet genom att lägga till <IncludeSetACLProviderOn Destination>False</IncludeSetACLProviderOnDestination> i publiceringsprofilfilen (för att påverka en enskild profil) eller till filen wpp.targets (för att påverka alla profiler). Information om hur du redigerar dessa filer finns i Så här redigerar du distributionsinställningar i profilfiler (.pubxml).
Åtkomst nekades fel när en applikation försöker skriva till en applikationsmapp
Scenario
Ditt program får ett fel när det försöker skapa eller redigera en fil i en av programmapparna, eftersom det inte har skrivbehörighet för den mappen.
Möjlig orsak och lösning
Som standard anger Visual Studio läsbehörigheter på webbplatsens rotmapp och skrivbehörigheter för App_Data-mappen. Om ditt program behöver skrivåtkomst till en undermapp kan du ange behörigheter för den mappen enligt självstudierna Ange mappbehörigheter och Distribuera till produktionsmiljön i den här serien. Om ditt program behöver skrivåtkomst till rotmappen på webbplatsen måste du förhindra att det ställer in skrivskyddad åtkomst i rotmappen genom att lägga till <IncludeSetACLProviderOn Destination>False</IncludeSetACLProviderOnDestination> i publiceringsprofilfilen (för att påverka en enskild profil) eller till filen wpp.targets (för att påverka alla profiler). Information om hur du redigerar dessa filer finns i Så här redigerar du distributionsinställningar i profilfiler (.pubxml).
Konfigurationsfel – targetFramework-attributet refererar till en version som är senare än den installerade versionen av .NET Framework
Scenario
Du har publicerat ett webbprojekt som är avsett för ASP.NET 4.5, men när du kör programmet (med customErrors-läget inställt på "off" i filen Web.config) får du följande fel:
Attributet 'targetFramework' i <kompilering>-elementet i Web.config-filen används endast för version 4.0 och senare av .NET Framework (ett exempel: '<compilation targetFramework="4.0">'). Attributet targetFramework refererar för närvarande till en version som är senare än den installerade versionen av .NET Framework. Ange en giltig målversion av .NET Framework eller installera den version av .NET Framework som krävs.
Rutan Källfel på felsidan markerar följande rad från Web.config som orsaken till felet:
<compilation targetFramework="4.5" />
Möjlig orsak och lösning
Servern stöder inte ASP.NET 4.5. Kontakta värdleverantören för att avgöra när och om support för ASP.NET 4.5 kan läggas till. Om uppgradering av servern inte är ett alternativ måste du distribuera ett webbprojekt som riktar sig till ASP.NET 4 eller tidigare i stället.
Om du distribuerar ett ASP.NET 4 eller tidigare webbprojekt till samma mål markerar du kryssrutan Ta bort ytterligare filer vid målet på fliken Inställningar i guiden Publicera webbplats . Om du inte väljer Ta bort ytterligare filer vid målet, kommer du fortsätta att få sidan Konfigurationsfel.
Projektegenskaperna innehåller en listruta för Target Framework, men du kan inte lösa problemet genom att bara ändra det från .NET Framework 4.5 till .NET Framework 4. Om du ändrar målramverket till en tidigare ramverksversion kommer projektet fortfarande att ha referenser till den senare ramverksversionens sammansättningar och kommer inte att köras. Du måste ändra dessa referenser manuellt eller skapa ett nytt projekt som riktar sig till .NET Framework 4 eller tidigare. Mer information finns i .NET Framework-mål för webbplatser.
Medelhöga förtroendefel
Scenario
När du kör programmet i produktion får det ett fel som rör medelförtroende.
Möjlig orsak och lösning
Många tredjepartsvärdleverantörer kör din webbplats med medelhögt förtroende, vilket innebär att det finns vissa saker som det inte är tillåtet att göra. Programkoden kan till exempel inte komma åt Windows-registret och kan inte läsa eller skriva filer som ligger utanför programmets mapphierarki. Som standard körs programmet i fullständigt förtroende på den lokala datorn, vilket innebär att programmet kanske kan göra saker som skulle misslyckas när du distribuerar det till produktion.
Du kan konfigurera programmet så att det körs med medelhögt förtroende i den lokala IIS-miljön för att felsöka. Det gör du genom att öppna programmet Web.config fil och lägga till ett förtroendeelement i elementet system.web , som du ser i det här exemplet.
<configuration>
<!-- Settings -->
<system.web>
<trust level="Medium" />
<!-- Settings -->
</system.web>
</configuration>
Programmet körs nu med medelhögt förtroende för IIS även på den lokala datorn.
Gör inte detta om du distribuerar till Azure App Service eftersom Azure inte kräver medelhögt förtroende. När denna självstudie skrivs i februari 2012, kommer användningen av denna metod för att köra ditt program med medelhögt förtroende att orsaka ett fel i Azure.
Om du använder Entity Framework Code First Migrations och distribuerar till en värdleverantör som kör programmet med medelhögt förtroende kontrollerar du att version 5.0 eller senare är installerad. I Entity Framework version 4.3 kräver migreringar fullständigt förtroende för att uppdatera databasschemat.
HTTP 404.17 Fel: Fanns inte
Scenario
När du kör den distribuerade platsen på utvecklingsdatorn i IIS visas följande felmeddelande som rapporterar att servern inte kan bearbeta Default.aspx:
HTTP-fel 404.17 – Hittades inte
Det begärda innehållet verkar vara skript och hanteras inte av den statiska filhanteraren.
Möjlig orsak och lösning
ASP.NET 4.5 kanske inte är installerat på datorn. Se stegen i självstudietutorialen "Distribuera till IIS som en testmiljö" i den här serien, som förklarar hur du installerar ASP.NET 4.5.