Ik heb een ASP.NET Core-webapp ontwikkeld, grotendeels gebaseerd op de MVC-sjabloon in Visual Studio 2017 RC2. Het werkt prima in de lokale foutopsporingsmodus, maar wanneer ik het probeer te publiceren naar een door Azure gehoste web-app, krijg ik deze foutmelding:
Er is een fout opgetreden bij het starten van de applicatie.
.NET Core X86 v4.1.1.0 | Microsoft.AspNetCore.Hosting-versie
1.1.0-rtm-22752 | Microsoft Windows 6.2.9200
Ik heb geprobeerd stdoutLogEnabled="true"in te stellen in het web.config-bestand, maar het lijkt geen effect te hebben, de fout is hetzelfde.
Bijwerken:
Met wat hulp heb ik het logboek kunnen ophalen en er staat:
Application startup exception: System.TypeLoadException: Could not load type 'System.IO.File' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.
at Microsoft.Extensions.DependencyModel.FileWrapper.OpenRead(String path)
at Microsoft.Extensions.DependencyModel.DependencyContextLoader.LoadEntryAssemblyContext(IDependencyContextReader reader)
at Microsoft.Extensions.DependencyModel.DependencyContextLoader.Load(Assembly assembly)
at Microsoft.Extensions.DependencyModel.DependencyContext.Load(Assembly assembly)
at Microsoft.AspNetCore.Mvc.Internal.DefaultAssemblyPartDiscoveryProvider.DiscoverAssemblyParts(String entryPointAssemblyName)
at Microsoft.Extensions.DependencyInjection.MvcCoreServiceCollectionExtensions.GetApplicationPartManager(IServiceCollection services)
at Microsoft.Extensions.DependencyInjection.MvcCoreServiceCollectionExtensions.AddMvcCore(IServiceCollection services)
at Microsoft.Extensions.DependencyInjection.MvcServiceCollectionExtensions.AddMvc(IServiceCollection services)
at Bla.Api.Startup.ConfigureServices(IServiceCollection services) in C:\Users\user\Source\Workspaces\Bla\Bla.Api\src\Bla.Api\Startup.cs:line 73
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.AspNetCore.Hosting.ConventionBasedStartup.ConfigureServices(IServiceCollection services)
at Microsoft.AspNetCore.Hosting.Internal.WebHost.EnsureApplicationServices()
at Microsoft.AspNetCore.Hosting.Internal.WebHost.BuildApplication()
Hosting environment: Production
Content root path: D:\home\site\wwwroot
Now listening on: http://localhost:1264
Application started. Press Ctrl+C to shut down.
De coderegel waarnaar het verwijst op regel 73 is:
services.AddMvc();
Bijwerken:
Mijn global.json-bestand ziet er als volgt uit (waarbij Bla.Api de naam van het project is en het bestand zich in de hoofdmap van de oplossing bevindt).
{
"projects": [ "Bla.Api" ],
"sdk": {
"version": "1.1.0"
}
}
Antwoord 1, autoriteit 100%
Omdat veel verschillende problemen deze foutpagina kunnen veroorzaken, kan ik het volgende ten zeerste aanbevelen om de hoofdoorzaak snel en gemakkelijk te bepalen, zonder Azure (of welke server/platform dan ook) te worstelen om logboeken te krijgen.
U kunt uiterst nuttige ontwikkelaarsvriendelijke foutmeldingen bij het opstarteninschakelen door de .UseSetting("detailedErrors", "true")en .CaptureStartupErrors(true)acties in uw Program.cs-bestand.
Voor ASP.NET Core 1.x
public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseSetting("detailedErrors", "true")
.UseIISIntegration()
.UseStartup<Startup>()
.CaptureStartupErrors(true)
.Build();
host.Run();
}
(2018/07)Update voor ASP.NET Core 2.1
public class Program
{
public static void Main(string[] args)
{
BuildWebHost(args).Run();
}
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.CaptureStartupErrors(true)
.UseSetting("detailedErrors", "true")
.UseStartup<Startup>()
.Build();
}
- Deze instellingen moeten worden verwijderd zodra uw probleemoplossing is voltooid, om uw toepassing niet bloot te stellen aan kwaadaardige aanvallen.
Antwoord 2, autoriteit 6%
Maak verbinding via een sftp-client en verwijder alles in de site/wwwroot-map handmatig. Opnieuw publiceren
Ik heb alleen maar problemen gehad sinds ik een applicatie die ik op Azure heb gehost, heb gemigreerd naar .net core van MVC 4.
Op een gegeven moment was ik een paar weken geleden niet in staat om een project te laten draaien na een succesvolle publicatie. Ik heb zelfs twee keer geprobeerd om het hele App Service-profiel te verwijderen en opnieuw te maken met dezelfde naam. Toen ik echter een ‘2’ aan de App Service-naam toevoegde (om een nooit eerder gebruikte app-service te maken), werkte het publiceren van exact hetzelfde project met 0 wijzigingen perfect. Wat doet een verwijdering precies als ik met succes kan publiceren naar een nieuwe app-service, maar niet naar een verwijderde en opnieuw aangemaakte? Bestaande bestanden op bestemming verwijderen was aangevinkt bij elke publicatie, ook dat deed niets.
Ik had vandaag dezelfde fout als afgebeeld in de OP op mijn #2-site. Het deed zich voor na een poging om een aantal asp-nugetpakketten bij te werken en opnieuw te implementeren. Omdat ik echt niet naar iteratie myApp3 van mijn app-service wilde gaan, besloot ik de FTP-informatie op de azure-overzichtspagina te gebruiken. Ik navigeerde naar Site/wwwroot en verwijderde alles binnenin van de FTP-client. Ik heb toen de applicatie gepubliceerd en het werkte. Ik kan alleen maar concluderen dat het selectievakje ‘Verwijderen’ niet goed werkt.
Antwoord 3, autoriteit 5%
Iedereen bedankt voor jullie suggesties. Het enige dat uiteindelijk werkte, is het verwijderen van die Azure-webapp waarnaar ik niet kon publiceren en het maken van een geheel nieuwe. Ik vermoed dat sommige .dll’s uit de vorige runtime-omgeving nog steeds rondhingen of niet werden bijgewerkt… Wat het ook was, het opnieuw maken werkte. Hopelijk krijg ik deze foutmelding niet nog een keer, want dit soort dingen kun je niet echt doen in productie.
Wijzigingen aanbrengen in het bestand global.json leek geen effect te hebben.
Het maken van een geheel nieuwe API op basis van een sjabloon hielp ook niet, het probleem lag bij de Azure Web App zelf, aangezien alles lokaal goed werkte.
Een andere zeer nuttige tip was om logboekregistratie (en het “logs”-bestand in de root) toe te voegen volgens het andere antwoord. Dat wees me in ieder geval in de goede richting. Controleer ook uw runtime met dotnet --version.
Nogmaals bedankt voor de hulp van iedereen!
Antwoord 4, autoriteit 4%
Ik heb hetzelfde probleem. Gewoon niet geïmplementeerd bij Azure, ik gebruik mijn lokale machine als server en host deze in IIS.
An error occurred while starting the application.
.NET Core X64 v4.1.1.0 | Microsoft.AspNetCore.Hosting version 1.1.1 | Microsoft Windows 10.0.14393 | Need help?
En dit werd opgelost door web.config te wijzigen.
Eerste set stdoutLogEnabled = "true"
Zorg er dan voor dat stdoutLogFile=".\logs\stdout" />deze map bestaat.
En herstart IIS, je kunt het echte probleem vinden in het logbestand.
Antwoord 5, autoriteit 2%
VERWIJDERalle bestaande dll van wwwroot/your_application_folder en kopieer vervolgens alle uitvoerbestanden en -mappen voor publicatie.
Het probleem treedt op wanneer de NUGETS zichzelf bijwerkt. Als u de bestaande bestanden onder wwwroot/your_application_folder niet opschoont, geeft IIS de bovenstaande fout.
Antwoord 6, autoriteit 2%
Alles opschonen en opnieuw opbouwen.
Antwoord 7
Vraag is waarschijnlijk gedupliceerd – raadpleeg ASP.NET Core-hosting – 500 interne serverfout.
Snel antwoord:
Je moet het volgende instellen: stdoutLogEnabled="true"en stdoutLogFile=".\logs\stdout". U moet ook de map logshandmatig aanmaken.
Antwoord 8
In mijn geval was dat omdat ik gebruikersgeheimen probeerde te publiceren voor gebruik met Fabook OAuth. Ik weet dat dit een zeer situatiespecifiek antwoord is, maar OAuth lijkt tegenwoordig vrij gebruikelijk. Gebruikersgeheimen, zo blijkt, zijn niet bedoeld om te worden gepubliceerd. Wie wist.
Dus om dit te testen heb ik tijdelijk de volgende code gewijzigd in startup.cs. Deze gegevens mogen niet hard gecodeerd worden als onderdeel van de beste praktijken, omdat ze in duidelijke tekst in bronbeheer terecht zouden komen.
Vóór
app.UseFacebookAuthentication(new FacebookOptions()
{
AppId = Configuration["Authentication:Facebook:AppId"],
AppSecret = Configuration["Authentication:Facebook:AppSecret"]
});
Na
app.UseFacebookAuthentication(new FacebookOptions()
{
AppId = "0000000000000", // your value
AppSecret = "0000000000000000000000000000000" // your value
});
Toen werkte het.
Antwoord 9
In mijn geval was dat omdat ik wat gegevens probeerde te krijgen in Startup, en dbcontext werd niet bijgewerkt in de productieomgeving.
Mijn ConnectionString gewijzigd in Productie en Update-Database uitgevoerd, en probleem opgelost.
Antwoord 10
In mijn geval was er een map met de naam Resources die ontbrak in de app-map.