Nous créons notre application Web avec des pipelines Azure DevOps et nous la déployons dans Azure avec une version Azure DevOps. Je pense qu'aujourd'hui, netcore a été mis à jour vers netcore 3.1.4 sur notre agent de construction. Mais maintenant, notre déploiement Azure DevOps échoue, car le runtime netcore 3.1.4 n'est pas encore installé sur notre service d'application dans Azure.
Le message d'erreur que nous recevons:
Could not find 'aspnetcorev2_inprocess.dll'. Exception message:
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '3.1.4' was not found.
- The following frameworks were found:
2.2.8 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.0.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.1 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
You can resolve the problem by installing the specified framework and/or SDK.
Cela a du sens et peut arriver, mais quelle est la meilleure façon de résoudre ce problème?
Je pourrais fixer ma version à une version spécifique de netcore. Mais je n'aime pas cela, car nous voulons continuer à mettre à jour vers des versions plus récentes, mais nous ne voulons pas d'une version qui n'est pas disponible dans le service d'application Azure.
Ai-je raison de penser que nous devrions installer nos services de manière autonome, car sinon nous pourrions nous retrouver dans ce problème plus souvent quand Azure DevOps est plus rapide avec l'installation de correctifs qu'Azure?
Ou existe-t-il un moyen de forcer la mise à jour du service d'application Azure vers le nouveau correctif de sécurité netcore 3.1.4 qui serait idéal je pense?
J'ai juste besoin de quelques conseils sur meilleure approche pour résoudre ce problème?
4 Réponses :
Dans le passé, j'ai rencontré la même situation, vous pouvez résoudre ce problème en définissant manuellement la valeur de la liste déroulante RunTime Stack. Si vous mettez à jour manuellement le fichier .yml des processus de construction
RuntimeStack: 'DOTNETCORE|3.1'
Si vous souhaitez que la version de netcore soit automatiquement mise à jour au fur et à mesure qu'une version mise à jour est disponible, la création de notre service en tant que conteneur autonome semble être une bonne option: pas besoin d'installer quoi que ce soit sur la machine en cours d'exécution (c'est-à-dire la version sur Azure DevOps et Azure Web App ne doivent pas nécessairement correspondre).
Le principal inconvénient de cette approche est que la construction va être moins déterministe: exécuter votre compilation deux fois avec le même commit peut créer des binaires différents en fonction de ce qui est actuellement installé sur l'agent de compilation. si vous voulez en savoir plus, ici est un article intéressant expliquant pourquoi la construction déterministe est importante.
Pour que la construction reste déterminante, vous pouvez utiliser le Utilisez la tâche .Net Core au début de la construction (cela garantira que la version souhaitée du sdk dotnet est sur l'agent). Vous pouvez également ajouter un global.json dans votre référentiel pour verrouiller à la fois la compilation sur votre boîte de développement et dans Azure Dev Ops.
Il s'agit d'un sujet de discussion courant , et vous pouvez trouver de nombreux blogs prônant l'un ou l'autre côté.
De grandes discussions ont commencé lorsque Microsoft a publié LTS net core 3.1 et il a fallu un certain temps avant qu'Azure ne prenne également en charge le runtime 3.1.
Vous pouvez trouver de nombreux blogs suggérant fortement de déployer vos applications Web de manière autonome (la taille du runtime est d'environ 100 Mo) et de supprimer la dépendance envers Microsoft prenant en charge le dernier runtime. Alors que d'autres préconisent que les applications restent aussi légères que possible et que le temps d'exécution doit être défini dans le pipeline. Mais cela dépend toujours de vous. Moi-même, je préfère déployer des applications autonomes après ma mauvaise expérience avec net-core 3.1.
Il n'y a pas de bonnes pratiques établies.
Ou y a-t-il un moyen de forcer la mise à jour du service d'application Azure vers le nouveau correctif de sécurité netcore 3.1.4 qui serait idéal je pense?
AFAIK, il n'existe pas de moyen de forcer la mise à jour du service d'application Azure vers le nouveau netcore 3.1.4 .
Nous pourrions suivre les dernières versions sur https://aspnetcoreon.azurewebsites.net/ , mais nous n'avons pas pu le mettre à jour pour le moment.
Pour résoudre ce problème, nous vous recommandons de publier votre application en tant que autonome produit une application, qui inclut le runtime et les bibliothèques .NET Core, ainsi que votre application et ses dépendances. Les utilisateurs de l'application peuvent l'exécuter sur une machine sur laquelle le runtime .NET Core n'est pas installé.
La publication de votre application autonome produit un exécutable spécifique à la plate-forme. Le dossier de publication de sortie contient tous les composants de l'application, y compris les bibliothèques .NET Core et l'environnement d'exécution cible. L'application est isolée des autres applications .NET Core et n'utilise pas de runtime partagé installé localement. L'utilisateur de votre application n'est pas obligé de télécharger et d'installer .NET Core.
Vous pouvez consulter ce document .NET Core Présentation de la publication d'applications pour plus de détails.
J'espère que cela vous aidera.
Je vais aller de l'avant et construire autonome. Ce serait formidable s'il y avait un agent de build «compatible Azure» dans Azure DevOps, qui ne dispose que de mises à jour également installées sur Azure
@ErikSteinebach, C'est une bonne idée, mais pour l'instant, ce n'est peut-être pas facile à mettre en œuvre. BTW, si la réponse ci-dessus a résolu votre question, vous pouvez l'accepter comme réponse, afin qu'elle puisse aider d'autres membres de la communauté qui rencontrent les mêmes problèmes et nous pourrions archiver ce fil, merci.
Pour info, pour tous ceux qui ont la même question: je vais aller de l'avant et construire de manière autonome afin que nous ne rencontrions plus ce problème. Je pense que dans notre cas, cela a le plus de sens