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:
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).
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.
Quelques options pour obtenir le fichier .exe ici. Chacune de ces méthodes a fonctionné pour moi:
Basculez la configuration de construction de Debug
(valeur par défaut) à Release
:
dotnet publish -c Release
ou msbuild argument /p:Configuration=Release
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>
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: