web-dev-qa-db-fra.com

ASP.NET Core - ProcessPath incorrect dans le fichier Web.config généré

J'ai un problème assez étrange.

Une des applications sur laquelle nous travaillons a cessé de fonctionner après la publication dans Azure Web App. Tout fonctionne bien localement. Après de longues recherches, le coupable est que le web.config généré par la construction (dans VSTFS) a ceci:

<aspNetCore processPath=".\SomeServiceName.Api " stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Alors que le bon est: <aspNetCore processPath=".\SomeServiceName.Api.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Notez le .exe manquant .

La sortie du projet du projet est définie sur Application console. Il s’agit de l’application ASP.NET Core, qui s’exécute sur un cadre complet. La génération est exécutée à l'aide de la tâche Visual Studio Build dans VSTS, avec les éléments MSBuildArguments suivants:

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)"

Si j'exécute la compilation sur ma machine de développement en utilisant MSBuild cli avec les mêmes arguments de ligne de commande, j'obtiens ceci:

<aspNetCore processPath="dotnet" arguments=".\SomeServiceName.Api.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Le projet utilise <Project Sdk="Microsoft.NET.Sdk.Web">.

J'imagine que je pourrais simplement ajouter web.config au projet (il n'y en a plus du tout à présent) et le laisser contrôler le code source comme je le souhaite, ce qui devrait résoudre mon problème immédiat de déploiements interrompus. Mais j'aimerais savoir:

  1. Le web.config généré par la construction sur VSTS est évidemment faux. Est-ce un bogue dans Microsoft.NET.SDK.Web?
  2. Je n'ai pas accès au serveur de construction actuall. Je suppose que la seule explication raisonnable est que quelqu'un a mis à jour le SDK .net principal, ce qui explique pourquoi le comportement a changé. Est-ce que ça a du sens? Les cibles msbuild proviennent-elles du .NET Core SDK, ou est-ce que cela fait partie de visual studio?
  3. Je reçois différents web.config sur ma machine. Pourquoi donc?

Mise à jour :
Pour ceux qui trébuchent ici, voici le lien pour la publication sur github: https://github.com/aspnet/websdk/issues/408
On dirait que ceci est maintenant corrigé et fera partie de certaines versions un jour (aucune idée du cycle de publication).

asp.net-coremsbuild
9
Botis

J'avais exactement le même problème et je l'ai résolu la semaine dernière ... Nous avions 2 projets ASP.Net Core, l'un montrant le problème, l'autre non. Nous avons donc comparé les 2 fichiers .csproj.

Il s’avère que dans notre cas, tout ce que nous devions faire était de supprimer le 

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
  <PlatformTarget>AnyCPU</PlatformTarget>
</PropertyGroup>

propriétés du .csproj; Une fois cela fait, MSBuild a correctement créé le fichier web.config, y compris le fichier .exe à la fin du processus chemin.

3
LoZeno

Quelques options pour obtenir le fichier .exe ici. Chacune de ces méthodes a fonctionné pour moi:

  1. Basculez la configuration de construction de Debug (valeur par défaut) à Release:

    dotnet publish -c Release ou msbuild argument /p:Configuration=Release

  2. Créez un fichier Web.config comme vous le souhaitez à la racine de votre projet, puis dites au SDK de ne pas le toucher en ajoutant ce qui suit dans votre fichier de projet:

    <PropertyGroup> <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled> </PropertyGroup>

  3. Spécifiez votre environnement d'exécution cible comme l'un des environnements d'exécution gagnant- * répertoriés dans https://docs.Microsoft.com/en-us/dotnet/core/rid-catalog . Voici le code qui semble ajouter l'extension .exe:

    https://github.com/aspnet/websdk/blob/6b898ad0a39329ab5f0db281a9c1712e4303ed61/src/Publish/Microsoft.NET.Sdk.Publish.Targets/netstandard1.0/fr/ L44

1
phehr