J'ai rencontré des problèmes pour envoyer une demande à mon API ASP.NET Core 64 bits exécutée sur un Azure App Service. L'erreur que je récupère est:
Exception non gérée: System.BadImageFormatException: impossible de charger le fichier ou l'assembly '***. Dll'. Une tentative a été effectuée pour charger un programme avec un format incorrect.
Je comprends que cela signifie qu'il y a un décalage entre la plate-forme de l'application (64 bits) et celle de l'environnement sur lequel elle fonctionne. Je n'arrive pas à comprendre comment changer App Service pour qu'il fonctionne en 64 bits.
Dans les paramètres d'application du portail Azure, j'ai défini la plate-forme sur 64 bits:
Cependant, lorsque j'archive Kudu, l'environnement d'exécution indique qu'il fonctionne sous win8-x86:
project.json
"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true,
"platform": "x64"
},
"runtimes": {
"win10-x64": {}
}
Quelques questions
win8...
lorsque ma configuration d'exécution dans project.json
spécifie win10...
. Vraisemblablement x86 vs x64 est important, mais doit-il également être la même version de Windows. win8 vs win10.Ceci est désormais disponible dans Azure App Service.
Étapes à déployer:
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
dotnet publish
il suffit d'ajouter -r win-x64
)La documentation est ici mais (à l'heure actuelle), il est reconnu qu'elle est un peu rare.
Cette réponse au problème github suggère que nous devrions être en mesure de faire un déploiement dépendant du framework et de le faire "simplement fonctionner". YMMV mais ce n'était pas ma propre expérience, d'où la suggestion d'indicateur d'exécution ci-dessus
TLDR; Les processus de base .NET 64 bits utilisant le runtime de base .NET (par opposition au runtime .NET Framework) ne sont pas encore pris en charge sur Azure mais devraient arriver à l'avenir.
Voici des discussions que j'ai eues avec le support de Microsoft Azure.
La configuration 64 bits/32 bits sur le portail Azure (illustrée ci-dessus dans ma capture d'écran), contrôle le processus IIS w3wp.exe. Le processus w3wp.exe transmet les demandes à votre processus principal NET. La configuration ne fonctionne pas '' t contrôler le débit du processus de base .NET. C'est un peu déroutant, mais cela explique pourquoi la modification de l'option Platform dans la capture d'écran ci-dessus n'a eu aucun effet.
Sur la base du paramètre de variable d'environnement PATH du service d'application, dotnet.exe est mappé sur celui 32 bits, qui est "D:\Program Files (x86)\dotnet\dotnet.exe". Le runtime 64 bits de .NET core n'est pas préinstallé dans les services d'application, par conséquent, il n'est actuellement pas disponible.
Microsoft prévoit d'ajouter une prise en charge 64 bits aux applications de base .NET exécutées sur le runtime de base .NET dans Azure, mais cela dépend d'une future mise à jour de la chaîne d'outils de base .NET. Ils m'ont donné une date interne estimée mais j'ai promis de ne pas la partager publiquement.
Une solution de contournement qu'ils m'ont donnée était d'utiliser le modèle de studio visuel ASP.NET core (en utilisant le framework .net), et non le core ASP.NET (en utilisant le noyau .net). Celui-ci charge le runtime du cadre .Net 64 bits pour votre application Web principale ASP.Net. Cela nécessitera un peu de travail de migration et je suppose que cela peut ne pas être possible pour certains projets.
Heureusement, j'ai pu passer à des versions 32 bits de certaines de mes dépendances, ce qui signifiait que l'application fonctionnait dans l'environnement Azure. Malheureusement, cela ne signifie pas grand-chose pour ceux qui n'ont pas cette option, et je suis sûr qu'il y en a beaucoup.
Si vous avez besoin d'un runtime 64 bits, il existe 4 façons de procéder:
Voir plus de détails sur la façon de le faire dans le lien ci-dessous: https://blogs.msdn.Microsoft.com/webdev/2018/01/09/64-bit-asp-net-core-on-Azure -app-service /
Crédits à: Glenn Condron
la commande dotnet publish génère un fichier web.config qui est utilisé par IIS pour démarrer le processus dotnet. Dans Kudu, dans la variable d'environnement PATH dotnet.exe est de D:\Program Files ( x86)\dotnet
La solution consiste à remplacer dans ce fichier après la construction
<aspNetCore processPath="dotnet" arguments=...
avec:
<aspNetCore processPath="%ProgramFiles%\dotnet\dotnet" arguments=...