web-dev-qa-db-fra.com

Classes de démarrage multiples Dotnet Core avec hébergement en cours

J'ai une application dotnet core v.2.1 qui utilise la "convention de nom de classe de démarrage par environnement" pour utiliser différentes classes Startup pour un environnement différent, par exemple développement, mise en scène et production. La méthode Program.Main.CreateWebHost Ressemble à ceci:

public static IWebHostBuilder CreateWebHostBuilder(string[] args)
{
    var startupAssembly = Assembly.GetExecutingAssembly();
    var webHostBuilder = WebHost.CreateDefaultBuilder(args)
                                .UseStartup(startupAssembly.FullName);
    return webHostBuilder;
}

Cependant, après la mise à niveau vers dotnet core v.2.2 (et la commutation de démarrage fonctionne toujours très bien), je voulais essayer les capacités d'hébergement en cours. Lors du passage au modèle d'hébergement en cours de traitement et de l'exécution locale avec Visual Studio 2017 mis à jour et IIS Express, j'obtiens cette erreur en exécutant l'application:

Erreur HTTP 500.30 - Échec de démarrage du processus ANCM

Causes courantes de ce problème:

  • L'application n'a pas pu démarrer
  • L'application a démarré puis s'est arrêtée
  • L'application a démarré mais a levé une exception lors du démarrage

Étapes de dépannage:

  • Vérifiez le journal des événements système pour les messages d'erreur
  • Activer la journalisation des messages stdout du processus d'application
  • Attachez un débogueur au processus de demande et inspectez

Pour plus d'informations, visitez: https://go.Microsoft.com/fwlink/?LinkID=2028265

J'ai vérifié tous les journaux et je n'ai trouvé que ceci:

<Event xmlns="http://schemas.Microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="IIS Express AspNetCore Module V2" /> 
    <EventID Qualifiers="0">1007</EventID> 
    <Level>2</Level> 
    <Task>0</Task> 
    <Keywords>0x80000000000000</Keywords> 
    <TimeCreated SystemTime="2018-12-14T10:37:48.327935100Z" /> 
    <EventRecordID>3693</EventRecordID> 
    <Channel>Application</Channel> 
    <Computer>[whatever]</Computer> 
    <Security /> 
  </System>
  <EventData>
    <Data>Application '/LM/W3SVC/2/ROOT' with physical root '[whatever again]' failed to load clr and managed application. CLR worker thread exited prematurely</Data> 
    <Data>Process Id: 29836.</Data> 
    <Data>File Version: 12.2.18316.0. Description: IIS ASP.NET Core Module V2 Request Handler. Commit: ce8cf65589734f82b0536c543aba5bd60d0a5a98</Data> 
  </EventData>
</Event>

J'ai lu tous les migrations 2.1 hébergées par dotnet core -> 2.2 quels que soient les articles MSDN que j'ai pu trouver, et j'ai essayé un tas de configurations différentes, mais je n'ai trouvé aucune solution en dehors de l'utilisation par défaut:

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
           .UseStartup<Startup>();

... Ce qui ne fonctionnera pas - je veux utiliser le démarrage-commutation ensemble avec l'hébergement en cours. Quelqu'un sait-il comment y parvenir ou a-t-il des suggestions sur la façon de procéder au dépannage?

EDIT: J'ai reçu la réponse dont j'avais besoin de @cilerler. Par souci d'exhaustivité, voici ce qui se passait dans mon cas:

Le chargement de mes fichiers de configuration personnalisés a échoué car ce processus dépendait d'un appel à Directory.GetCurrentDirectory(), dont le résultat change lors du passage à l'hébergement in-process. Voici mon code d'origine pour cette partie (raccourci pour plus de concision):

var basePath = $"{Directory.GetCurrentDirectory()}\\ConfigurationFiles";
builder.SetBasePath(basePath);

builder.AddJsonFile("some.config.json", false, true);
builder.AddJsonFile($"some.config.{context.HostingEnvironment.EnvironmentName}.json", true, true);

La partie cruciale est - encore une fois - l'appel à GetCurrentDirectory(), donc, pour résoudre le problème, j'ai changé ce qui précède conformément à la recommandation de la réponse acceptée, en:

var currentDirectory = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
var basePath = $"{currentDirectory}\\ConfigurationFiles";
builder.SetBasePath(basePath);

Pour plus de détails, voir la réponse acceptée;)

c#.net-coreiis-express-10
11
Oskar Lindberg

Selon aspnet-core-module l'article dit

GetCurrentDirectory renvoie le répertoire de travail du processus démarré par IIS plutôt que le répertoire de l'application (par exemple, C:\Windows\System32\inetsrv pour w3wp.exe).

ce qui signifie que le chargeur de configuration ne pourra pas trouver les fichiers appsettings.*, ou tout autre fichier tels que les fichiers de configuration personnalisés, qui dépendent d'un appel GetCurrentDirectory. Afin de le résoudre dans votre Program.cs juste après public static void Main(string[] args) { ajoutez la ligne suivante

Directory.SetCurrentDirectory(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location));

Aussi, dans le fichier de projet (par exemple MyProject.csproj ) assurez-vous que vous disposez des lignes suivantes et appsettings.* Existe dans le dossier de sortie.

<ItemGroup>
  <Content Update="appsettings.json">
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
  </Content>
  <Content Update="appsettings.Development.json">
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
  </Content>
  <Content Update="appsettings.Production.json">
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
  </Content>
</ItemGroup>
9
cilerler

J'ai eu le même problème, une histoire différente.

Visual Studio 2017 - asp.net core mvc (sdk 2.2.104).

  1. Exécutez l'application. (oui cela vous donnera à nouveau l'erreur)
  2. dans VS, accédez aux paramètres d'exception et activez les exceptions C++, les exceptions CLR et les exceptions Win32
  3. Redémarrez votre progression de débogage et voyez si une exception est levée.

Dans mon cas: j'ai enregistré un service dans Startup.cs via .AddScoped où le paramètre concret serviceType était en fait une classe abstraite (j'ai oublié de changer cela après refactoring).

Sinon, accédez à l'Observateur d'événements Windows et essayez de trouver un indice dans les journaux.

0
juFo