ASP.NET Core 1.1 fonctionne correctement localement, mais lors de la publication dans Azure, il indique "Une erreur s'est produite lors du démarrage de l'application."
J'ai développé une application Web ASP.NET Core, largement basée sur le modèle MVC fourni dans Visual Studio 2017 RC2. Il fonctionne très bien en mode débogage local, mais lorsque j'essaie de le publier sur une application Web hébergée sur Azure, le message d'erreur suivant s'affiche:
Une erreur s'est produite lors du démarrage de l'application.
.NET Core X86 v4.1.1.0 | Version Microsoft.AspNetCore.Hosting 1.1.0-rtm-22752 | Microsoft Windows 6.2.9200
J'ai essayé de définir stdoutLogEnabled="true" dans le fichier web.config, mais il semble n'avoir aucun effet, l'erreur est la même.
Mettre à jour:
Avec de l'aide, j'ai réussi à récupérer le journal et il est écrit:
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.
La ligne de code à laquelle il fait référence à la ligne 73 est la suivante:
services.AddMvc();
Mettre à jour:
Mon fichier global.json ressemble à ceci (où Bla.Api est le nom du projet et le fichier se trouve dans le dossier racine de la solution).
{
"projects": [ "Bla.Api" ],
"sdk": {
"version": "1.1.0"
}
}
Merci à tous pour vos suggestions. Cependant, la seule chose qui a fonctionné à la fin est de supprimer cette application Web Azure pour laquelle je ne pouvais pas publier et de créer une nouvelle. J'imagine que certains des fichiers .dll de l'environnement d'exécution précédent traînaient encore ou n'étaient pas mis à jour ... Quoi qu'il en soit, recréer cela fonctionnait. Si tout va bien, je ne reçois pas cette erreur encore, parce que vous ne pouvez pas vraiment faire ce genre de choses en production.
Les modifications apportées au fichier global.json semblaient n'avoir aucun effet.
La création d'une nouvelle API à partir d'un modèle n'a pas aidé non plus, le problème était lié à l'application Web Azure elle-même, car tout fonctionnait correctement au niveau local.
Une autre astuce très utile a été d'ajouter la journalisation (et le fichier "logs" à la racine) conformément à l'autre réponse. Cela m'a au moins orienté dans la bonne direction. Vérifiez également votre runtime avec dotnet --version.
Encore merci pour l'aide de tous!
Étant donné que de nombreux problèmes peuvent être à l'origine de cette page d'erreur, je vous recommande vivement les mesures suivantes afin de déterminer la cause première rapidement et facilement, sans lutter contre Azure (ou tout autre serveur/plate-forme) pour obtenir des journaux.
Vous pouvez activer des messages extrêmement utiles messages d'erreur destinés aux développeurs au démarrage en définissant les actions .UseSetting("detailedErrors", "true") et .CaptureStartupErrors(true) dans votre fichier Program.cs.
Pour 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) _ Mise à jour pour 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();
}
- Ces paramètres doivent être supprimés dès que votre dépannage est terminé afin de ne pas exposer votre application à des attaques malveillantes.
Connectez-vous via un client sftp et supprimez manuellement tous les éléments du dossier site/wwwroot. Republier
Je n'ai rencontré que des problèmes depuis la migration d'une application hébergée sur Azure vers le noyau .net à partir de MVC 4.
Il y a quelques semaines, j’ai été incapable de lancer un projet après une publication réussie. J'ai même essayé deux fois de supprimer le profil entier App Service et de le recréer avec le même nom. Cependant, lorsque j'ai ajouté un «2» au nom du service d'application (pour créer un service d'application jamais utilisé auparavant), la publication exacte du même projet avec 0 modification a parfaitement fonctionné. Que fait exactement une suppression si je peux publier avec succès sur un nouveau service d'application mais pas sur un service supprimé et recréé? Supprimer les fichiers existants à la destination a été coché à chaque publication, cela n'a rien fait non plus.
J'ai eu la même erreur aujourd'hui que celle illustrée dans l'OP de mon site n ° 2. Cela s'est produit après une tentative de mise à jour et de redéploiement d'un certain nombre de packages de nuget asp. Ne souhaitant vraiment pas passer à l'itération myApp3 de mon service d'application, j'ai décidé d'utiliser les informations FTP fournies dans la page de présentation Azure. J'ai navigué sur Site/wwwroot et j'ai tout supprimé du client FTP. J'ai ensuite publié l'application, et cela a fonctionné. Je ne peux que conclure que la case à cocher «Supprimer» ne fonctionne pas correctement.
J'ai le même problème. Non déployé chez Azure, j'utilise mon ordinateur local comme serveur et l'héberge dans 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?
Et cela a été résolu en changeant web.config.
Premier ensemble stdoutLogEnabled = "true"
Ensuite, assurez-vous que stdoutLogFile=".\logs\stdout" /> ce dossier existe.
Et puis redémarrez IIS, vous pouvez trouver le vrai problème dans le fichier journal.
DELETEtoutes les dll existantes de wwwroot/your_application_folder, puis copiez tous les fichiers et dossiers de sortie de publication.
Le problème se produit lorsque le NUGETS se met à jour automatiquement. Si vous ne nettoyez pas les fichiers existants sous wwwroot/votre_application_folder IIS, l'erreur ci-dessus est générée.
La question est probablement dupliquée - veuillez vous référer à Hébergement ASP.NET Core - Erreur de serveur interne 500 .
Réponse rapide:
Vous devez définir: stdoutLogEnabled="true" et stdoutLogFile=".\logs\stdout". En outre, vous devez créer le dossier logs manuellement.
Dans mon cas, c’est parce que j’essayais de publier des secrets d’utilisateur pour les utiliser avec Fabook OAuth. Je sais que c'est une réponse très spécifique à la situation, mais OAuth semble assez commun de nos jours. Il s'avère que les secrets de l'utilisateur ne sont pas destinés à être publiés. Qui savait.
Donc, pour tester cela, j'ai temporairement changé le code suivant dans startup.cs. Ces données ne doivent pas être codées en dur dans le cadre des meilleures pratiques, car elles se retrouveraient en texte clair dans le contrôle de source.
Avant
app.UseFacebookAuthentication(new FacebookOptions()
{
AppId = Configuration["Authentication:Facebook:AppId"],
AppSecret = Configuration["Authentication:Facebook:AppSecret"]
});
Après
app.UseFacebookAuthentication(new FacebookOptions()
{
AppId = "0000000000000", // your value
AppSecret = "0000000000000000000000000000000" // your value
});
Ensuite cela a fonctionné.
Dans mon cas, c’est parce que j’essayais d’obtenir des données dans Startup et que dbcontext n’était pas mis à jour dans un environnement de production.
Changement de ConnectionString en Production et mise à jour de la base de données et résolution du problème.