Aws-lambda-dotnet: .NET Core 3.1 (LTS) est sorti

C'est un LTS et sera pris en charge. Il faudra juste un certain temps pour que .NET Core 3.1 soit prêt pour Lambda et déployé.

C'est un LTS et sera pris en charge. Il faudra juste un certain temps pour que .NET Core 3.1 soit prêt pour Lambda et déployé.

Si je peux faire quelque chose pour vous aider, faites-le moi savoir.

Y aura-t-il une accélération pour l'heure de démarrage à froid ?

.NET Core 3.1 a certaines fonctionnalités comme la compilation AOT

• PublierPrêtPourExécuter
• PublierDécoupé

@normj les gens devraient-ils s'abonner à ce problème pour les mises à jour ou existe-t-il un autre problème .NET Core 3.1 que nous devrions suivre pour progresser ?

Nous pouvons utiliser ce problème pour suivre les mises à jour. Malheureusement, je ne serai probablement pas en mesure de fournir une grande partie des mises à jour de statut jusqu'à ce qu'il soit sorti.

Y aura-t-il une accélération pour l'heure de démarrage à froid ?

.NET Core 3.1 a certaines fonctionnalités comme la compilation AOT

• PublierPrêtPourExécuter
• PublierDécoupé

Si la réponse est oui pour le commentaire, sera-t-il possible d'exécuter et de tester le « lambda compilé » à partir d'un environnement local ? Je définirais avec impatience un environnement Linux pour cela :)

Une mise à jour ici ?

@rati-dzidziguri

Comme ci-dessus de @normj

Nous pouvons utiliser ce problème pour suivre les mises à jour. Malheureusement, je ne serai probablement pas en mesure de fournir une grande partie des mises à jour de statut jusqu'à ce qu'il soit sorti.

@beeradmoore
Ma question portait sur l'ETA. Il serait utile de connaître l'ETA pour cela, car nous pourrions nous préparer en conséquence.

@rati-dzidziguri Amazon divulgue rarement son ETA en ce qui concerne les sorties.

@rati-dzidziguri Je comprends et j'apprécie que vous souhaitiez un ETA afin que vous puissiez planifier en conséquence. En réalité, c'est pour cette raison que nous ne donnons généralement pas d'ETA parce que nous nous efforçons vraiment de ne pas faire de promesses que nous ne sommes pas sûrs à 100% de pouvoir tenir. Je détesterais vous donner un ETA et que vous fassiez votre feuille de route sur cette base et nous manquons alors cet ETA que vous attendiez, ce qui bouleverse tous vos plans.

Pour l'instant, si vous avez vraiment besoin des fonctionnalités .NET Core 3.1, je vous suggère d'utiliser .NET Core 3.1 en tant que Lambda Custom Runtime, ce qui est expliqué ici (sauf pour modifier les références de .NET Core 3.0 à .NET Core 3.1). Ensuite, lorsque la prise en charge native de .NET Core 3.1 arrivera, vous aurez une migration très simple consistant à modifier quelques paramètres de votre fonction Lambda.

@normj L'une des raisons m'a fait décider que je ne peux pas utiliser la fonctionnalité d'exécution personnalisée avec la classe "LambdaEntry" est l'aspect "architecture monolithique" de l'approche de mise en œuvre. Chaque demande d'API passe par la seule entrée lambda et "distribuée" aux contrôleurs du projet ASP .net est ce que la structure d'exécution personnalisée voulait, ce qui est certainement pratique mais inclut un inconvénient structurel pour les cas comme je le souhaite. Je veux que chaque demande de commande/requête devienne lambda chacune. Depuis lors, je peux obtenir une évolutivité sur la gestion des packages de déploiement que je peux diviser certaines fonctions et gérer les codes à tout moment.
C'est pourquoi j'attends que le runtime officiel soit pris en charge pour que je puisse construire un ensemble de « lambdas à usage unique » en utilisant SAM écrit dans un modèle avec la configuration « runtime : .netcore 3.1 ».

Merci de me conseiller si je me trompe :)

Vous pouvez certainement réaliser plusieurs fonctions lambda à partir d'une base de code à l'aide du programme d'amorçage Lambda et de la fonction d'exécution personnalisée.

J'ai une suite de 16 lambdas qui sont déployés à partir d'une seule application, plutôt qu'un « monolithe ».

Ceci est réalisé en utilisant la variable d'environnement _handler pour choisir la méthode à utiliser au moment de l'exécution, plutôt que le mappage un-à-un codé en dur indiqué dans l'exemple de code de l'article de blog.

Je le considère comme une application de console qui reçoit un commutateur qui lui indique quelle action « devenir » au démarrage.

@martincostello
Merci pour la gentille suggestion ! Je peux comprendre à quoi peut ressembler votre cas. Vous avez peut-être placé la logique de commutation dans la classe Main ou Startup afin de déterminer sa fonctionnalité lors de la première étape de l'exécution. Et cela peut résoudre le problème « uniquement monolithique », bien sûr. Approche très intelligente :)

Mais encore, il y a une (sinon plusieurs) considération à laquelle je dois penser, surtout quand j'imagine travailler en équipe. L'utilisation d'un runtime personnalisé et la détermination de « l'identité fonctionnelle » au démarrage élimineront la possibilité de SAM. Pour un exemple simple pour nous, la passerelle API ne peut pas être définie lors du déploiement d'un lambda, ce qui signifie que nous devons en générer un manuellement.
Je sais que j'exagère ici car nous pouvons créer une configuration de type SAM à l'aide du script d'amorçage, comme expliqué dans le didacticiel aws . Mais cela ne nous satisfera pas complètement car il utilise un script linux, ce qui signifie
(1) cela peut être embarrassant pour les nouveaux arrivants, et parfois cela deviendra une courbe d'apprentissage.
(2) il supprimera l'avantage de l'expressivité du modèle sans serveur car il s'agit littéralement d'un script, pas d'un document.

Je pense que le modèle sans serveur fonctionne comme un semi-document de ce à quoi ressemble le serveur et comment il fonctionne, qui ne sera pas seulement partagé au sein d'une équipe de développement, mais même avec des non-techniciens perspicaces. et SAM est un concept bien défini qui, dans un futur proche, ses représentations abstraites d'une application permettront d'être réutilisées par une autre équipe utilisant des langages et des plateformes totalement différents. Ces aspects me motivent toujours indéniablement à continuer à utiliser la fonctionnalité « modèle sans serveur ».

Quelques belles dates à venir pour sortir ce 25 déc, 1er janvier me viennent à l'esprit ;)

Joyeuses fêtes à tous, j'aimerais pouvoir vous donner à tous le runtime Lambda .NET Core 3.1 pour Noël, mais je pense que 2020 sera une année passionnante pour .NET et AWS.

Joyeuses fêtes à tous, j'aimerais pouvoir vous donner à tous le runtime Lambda .NET Core 3.1 pour Noël, mais je pense que 2020 sera une année passionnante pour .NET et AWS.

Pas de soucis, profitez des vacances ! Hâte de voir ce que vous nous réservez en 2020 ! :)

en attente de la prise en charge native de lambda sur .NetCore3.1

Il existe une limite de taille de disque pour les fonctions lambda. Je pense que c'est 250 Mo et lors de l'utilisation du runtime personnalisé, nous devons envoyer tous les assemblys de base asp.net avec notre application. J'ai atteint cette limite lorsqu'AWS décompressait mon package zip. J'ai dû faire un peu de nettoyage pour réduire l'espace utilisé par mon application. Lorsque le support natif est disponible, nous n'avons pas besoin de packager notre application avec les assemblys de .core.

Y a-t-il une estimation du moment où nous pouvons nous attendre à ce que cela soit publié?

Nous attendons la mise à niveau vers .Net core 3.1 jusqu'à ce qu'il y ait un support natif pour cela.

Y a-t-il une estimation du moment où nous pouvons nous attendre à ce que cela soit publié?

Nous attendons la mise à niveau vers .Net core 3.1 jusqu'à ce qu'il y ait un support natif pour cela.

Si vous revenez en arrière et lisez les réponses, vous lirez dans normj qu'ils ne donneront aucune estimation.

Si vous revenez en arrière et lisez les réponses, vous lirez dans normj qu'ils ne donneront aucune estimation.

Mmmm normalement -- oui. Mais si suffisamment de gens se présentent avec des fourches, alors peut-être qu'un indice d'une date de sortie sera donné pour apaiser les troubles :grin:

Je me souviens il y a quelque temps quand AWS a passé beaucoup de temps à préparer les images natives 2.1. Ils ont dit quelque chose à l'effet qu'ils ont repensé le processus pour rendre le déploiement des futures versions plus facile et plus rapide au stand-up. Entrez NetCore 3.1 et presque deux mois plus tard et il n'est toujours pas disponible :(

Vous savez qu'Azure avait cette image 3.1 disponible le jour 1. Je commence à comprendre pourquoi le gouvernement américain a choisi Azure comme fournisseur de cloud pour JEDI.

Nous venons d'obtenir le feu vert de nos parties prenantes pour commencer à cibler Azure en tant que fournisseur principal, laissant AWS en tant que sauvegarde. Avec des retards idiots comme celui-ci, je suis sûr que nous ne sommes pas les seuls.

Je me souviens il y a quelque temps quand AWS a passé beaucoup de temps à préparer les images natives 2.1. Ils ont dit quelque chose à l'effet qu'ils ont repensé le processus pour rendre le déploiement des futures versions plus facile et plus rapide au stand-up. Entrez NetCore 3.1 et presque deux mois plus tard et il n'est toujours pas disponible :(

Vous savez qu'Azure avait cette image 3.1 disponible le jour 1. Je commence à comprendre pourquoi le gouvernement américain a choisi Azure comme fournisseur de cloud pour JEDI.

Nous venons d'obtenir le feu vert de nos parties prenantes pour commencer à cibler Azure en tant que fournisseur principal, laissant AWS en tant que sauvegarde. Avec des retards idiots comme celui-ci, je suis sûr que nous ne sommes pas les seuls.

Je suis d'accord avec toi. Mon organisation n'autorise pas l'exécution personnalisée et nous sommes en quelque sorte bloqués avec 2.1. En ce qui concerne EF & Postgres ainsi que les opérations spatiales, c'est trop pénible. Nous attendions que cela soit fait. Dommage que ce ne soit pas encore fait.

Je me souviens il y a quelque temps quand AWS a passé beaucoup de temps à préparer les images natives 2.1. Ils ont dit quelque chose à l'effet qu'ils ont repensé le processus pour rendre le déploiement des futures versions plus facile et plus rapide au stand-up. Entrez NetCore 3.1 et presque deux mois plus tard et il n'est toujours pas disponible :(

Vous savez qu'Azure avait cette image 3.1 disponible le jour 1. Je commence à comprendre pourquoi le gouvernement américain a choisi Azure comme fournisseur de cloud pour JEDI.

Nous venons d'obtenir le feu vert de nos parties prenantes pour commencer à cibler Azure en tant que fournisseur principal, laissant AWS en tant que sauvegarde. Avec des retards idiots comme celui-ci, je suis sûr que nous ne sommes pas les seuls.

JEDI utilise-t-il .NET Core pour supposer que c'est la raison pour laquelle le gouvernement a opté pour Azure ?

Salut à tous,

Je travaille activement à la prise en charge de .NET Core 3.1 dans Lambda. Cela prend un certain temps car Microsoft a effectué beaucoup de travail sur la façon dont ils créent le runtime. Je travaille sur l'intégration de ces changements pour vous apporter un runtime natif.

@assyadh Merci ! Je ne crois pas que les retards soient « idiots » ; en fait, je préfère attendre une version solide et fonctionnelle. J'adore le fait qu'AWS Lambda prend en charge .NET Core et j'apprécie que vous continuiez à le prendre en charge, comme promis.

Je ne comprends pas l'envie. Ce n'est pas que nous n'ayons pas d'environnement LTS pour le moment.

Évidemment, nous voulons utiliser les nouveaux jouets, mais l'équipe .NET d'AWS ne dispose que d'une quantité fixe de ressources et ne peut pas tout faire à la fois.

De plus, je n'ai pas envie de me précipiter et de mettre à jour le temps d'exécution de toutes les fonctions de peur d'être en panne de service.

Tant mieux pour toi @JamesQMurphy , nous préférerions également que la version soit solide.

J'ai hâte de voir votre travail @assyadh.

"Je ne comprends pas l'envie."

Nous ne pouvons pas utiliser .NET Core 3.1 partagé dans une fonction lambda .NET Core 2.1, en fait, nous ne pouvons même pas utiliser de code .NET Core 2.2 partagé dans une fonction lambda .NET Core 2.1, nous avons donc récemment dû rétrograder à contrecœur notre composants partagés vers .NET Core 2.1 pour qu'ils soient pris en charge dans la fonction.

Vos composants partagés peuvent-ils être compilés en netstandard20 ? Ensuite, vous pouvez les partager dans netcore2&3

Bien que ce fil soit spécifique à .NET 3.1, je suis sûr que cette conversation exacte sera rejouée lorsque .NET 5 arrivera (ou 6 si ce sera le prochain LTS).

Bien que certains exemples spécifiques aient été cités où cela n'est pas possible (par exemple, fichier ZIP de code trop volumineux, politique de l'entreprise), _en général_ si vous souhaitez utiliser le « dernier et le meilleur » .NET Core à l'avenir, vous pouvez le faire avec un peu de refactorisation et le package de support d'exécution personnalisé.

En ce moment, il se trouve que nous sommes à un point où la dernière version _se trouve également_ être une version LTS, ce qui semble faire en sorte que le besoin de l'avoir « aussitôt que possible » d'Amazon semble beaucoup plus « urgent » qu'avec, disons, ayant un support intégré 2.2 ou 3.0.

En fin de compte, il y a un compromis à faire entre les nouvelles fonctionnalités utilisables sur Lambda et les efforts de développement nécessaires pour les solutions PaaS.

.NET Core 3.1 n'était même pas disponible sur Azure App Service de Microsoft pendant 2-3 semaines après sa sortie.

Si vous aimez généralement être à la pointe de la technologie dès que possible, un petit investissement dans l'utilisation du support d'exécution personnalisé à court terme vous permettra d'exécuter potentiellement toute future version de .NET Core dans Lambda à votre propre rythme. Bien sûr, le compromis ici est entre autres des packages plus volumineux, un peu plus de code et la nécessité de faire votre propre correctif.

Avec tout, il y a un équilibre et un compromis, et pour le support intégré, il y aura toujours un décalage de disponibilité car le logiciel prend du temps.

Avec les versions majeures de .NET à venir en novembre, la période de Noël/vacances aura probablement toujours un effet sur le temps que prendra la mise à disposition de ces éléments intégrés en termes de temps et de capacité disponible de l'équipe Lambda.

J'ajoute juste mes pensées. Je comprends à quel point cette version est très importante et je vous remercie de nous le dire. J'utilise ces commentaires pour pousser l'urgence de notre côté. Comme @martincostello l'a mentionné, le moment de la sortie de .NET Core 3.1 n'était pas génial en raison des vacances mais aussi pendant reInvent.

J'étais le gars qui a mentionné dans le passé pour la 2.1 que j'espérais que l'automatisation que nous avons mise en place accélérerait la future version. L'automatisation mise en place par @assyadh nous a vraiment aidés, mais malheureusement, au fur et à mesure que le logiciel évolue, les choses ont beaucoup changé depuis que nous avons créé .NET Core 2.1. Une partie est la façon dont MS construit .NET Core et l'autre est la façon dont le service Lambda fonctionne avec le passage à Amazon Linux 2.

Alors s'il vous plaît, croyez-moi que .NET Core 3.1 est @assyadh , moi-même et beaucoup d'autres la plus haute priorité à faire.

Juste pour vérifier, le travail pour l'incorporer commence-t-il une fois que Microsoft a publié les pré-versions plutôt que d'attendre la version finale ? Cela réduirait vraisemblablement l'impact de Noël et lui permettrait d'être livré plus tôt une fois la version finale publiée, car elle aurait juste besoin de tests.

J'utilise ces retours pour pousser l'urgence de notre côté

Merci pour cette @normj. Voici mon 0,02 $, dans l'espoir que cela aide également votre évangélisation.

Comme @martincostello l'a mentionné, le moment de la sortie de .NET Core 3.1 n'était pas génial en raison des vacances mais aussi pendant reInvent.

Comme @mungojam l'a mentionné, .NET Core 3.1 était disponible sous forme d'aperçu à partir du 15 octobre, plus d'un mois avant sa sortie. De plus, il s'agit essentiellement d'une version de correction de bogues de la version 3.0 - je ne connais pas vos outils, mais j'imagine que le travail exploratoire aurait pu commencer en utilisant la version 3.0, qui a été publiée le 23 septembre et en avant-première toute l'année . Il convient de noter que 3.1 a reçu une date de sortie estimée dans l'annonce de sortie 3.0.

.NET Core 3.1 n'était même pas disponible sur Azure App Service de Microsoft pendant 2-3 semaines après sa sortie.

.NET Core 3.1 était disponible sur Azure Functions le 17 octobre , deux jours après la publication de l'Aperçu 1.

Vous pouvez dire ce que vous voulez sur le besoin de n'importe quelle entreprise d'avoir 3.1 tout de suite, qu'il s'agisse d'un « bord de fuite », d'options d'exécution personnalisées, etc. les clients. Si AWS - pas l'équipe de Norm, mais AWS dans son ensemble - en avait fait une priorité, je dois penser qu'ils auraient pu être devant, en s'assurant qu'ils étaient en concurrence avec Azure.

Personnellement, j'apprécie vraiment d'avoir des options parmi les offres cloud que je peux choisir en fonction du mérite plutôt que du dogme de l'entreprise, et j'aimerais beaucoup qu'AWS franchisse une nouvelle étape dans l'amélioration de la prise en charge de .NET.

Merci @normj , @assyadh et tous ceux qui y travaillent pour vos efforts.

Il est possible que l'équipe .NET d'AWS ait très bien commencé son parcours de préparation pour .NET 3.1 LTS lors de la sortie de la préversion 3.0. Le fait est qu'AWS a tendance à être discret sur ce sur quoi ils travaillent en coulisses. Ce manque de transparence engendre des suppositions. Je pense que cela ne ferait pas de mal d'avoir une sorte de feuille de route, même si elle est provisoire et que les dates sont susceptibles de changer, etc.

Je pense que le problème est que l'équipe AWS ne veut publier aucune sorte d'ETA et donc les développeurs sont mis dans l'ignorance. @normj dit que c'est parce qu'il ne veut pas que quiconque ni aucune entreprise fasse des plans futurs sur la base de ces ETA. N'est-il pas généralement admis qu'un ETA n'est qu'une estimation et qu'aucune entreprise ne devrait faire de plans sérieux sur la base des estimations d'une autre entreprise et même si c'était le cas, l'entreprise ne peut pas blâmer AWS ou être en colère contre elle pour avoir manqué un ETA ?

Un ETA n'est pas non plus un jour spécifique. Cela peut être un mois. Un quart. Et nous devrions être d'accord avec n'importe quel ETA et d'accord s'il a été manqué.

Regarder
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html
il semble qu'AWS désapprouve l'environnement d'exécution peu de temps après la fin de vie de cette version d'exécution.

Étant donné que les versions .NET Core LTS sont prises en charge pendant 3 ans, nous sommes déjà
"passer le temps que nous pouvons utiliser les lambdas .NET Core 3.1".
Par conséquent, je comprends que les gens sont hospitalisés pour obtenir .NET core 3.1 sur lambdas.
BTW, je préférerais aussi une sortie solide comme le roc alors que quelque chose se précipite.

Je suppose qu'il sera disponible dans un ou deux mois, mais un certain engagement d'AWS,
même si très conservatrice pourrait être bénéfique pour les équipes pour planifier leurs opérations.

Une autre chose est qu'en cette période d'OSS : la communauté .NET peut-elle aider ? Nous parlons après tout sur github.
Ce runtime « intégré » est-il du code fermé ?

En outre, ce serait une fonctionnalité KILLER si le processus de déploiement avait un commutateur pour faire ReadyToRun et d'autres fonctionnalités de compilation AOT afin que les temps de démarrage à froid diminuent sérieusement.
Cela rendrait .NET Core TRÈS attrayant sur AWS Lambda, IMO.

@normj et équipe :
merci d'avoir rendu .NET core génial sur AWS

J'ajoute juste mes pensées. Je comprends à quel point cette version est très importante et je vous remercie de nous le dire. J'utilise ces commentaires pour pousser l'urgence de notre côté.

Veuillez utiliser ce message pour pousser l'urgence de votre côté. Dans cet esprit, voici mes deux centimes.

Juste pour vérifier, le travail pour l'incorporer commence-t-il une fois que Microsoft a publié les pré-versions plutôt que d'attendre la version finale ?

Question : Aurons-nous une réponse honnête à cette question ?

On a l'impression que la réponse va de soi. Il semble que la priorité pour .NET soit "au niveau des loisirs" et non "au niveau de l'entreprise" comme il se doit.

J'ai entendu quelque part que 1) tout le contenu de Net Core a été rendu open-source, et 2) qu'il existe des programmes d'adoption précoce qui vous permettent de "prendre le pied" dès la sortie réelle. (voir Google pour plus de détails.)

Je suis drôle ici, mais la vérité est que tous ceux qui suivent .NET le savent, donc cela ajoute à l'évidence dans laquelle je parle.

Honnêtement, après les retards de la version 2.1, j'espérais que les modifications apportées à l'époque signifiaient que cette fois-ci (3.1) nous aurions la prise en charge du nouveau framework pas plus de deux semaines après la sortie réelle. Je veux dire que quelques heures après la sortie serait idéal, mais donner un peu de place pour les touches finales / le polissage, dans les deux semaines, c'est à peu près correct.

Mais ici, nous avons presque deux mois d'absence et cela ressemble à un "passe-temps".

@rati-dzidziguri Je comprends et j'apprécie que vous souhaitiez un ETA afin que vous puissiez planifier en conséquence. En réalité, c'est pour cette raison que nous ne donnons généralement pas d'ETA parce que nous nous efforçons vraiment de ne pas faire de promesses que nous ne sommes pas sûrs à 100% de pouvoir tenir.

C'est une pensée "au niveau des loisirs", comme le dit si élégamment

Je pense que le problème est que l'équipe AWS ne veut publier aucune sorte d'ETA et donc les développeurs sont mis dans l'ignorance. @normj dit que c'est parce qu'il ne veut pas que quiconque ni aucune entreprise fasse des plans futurs sur la base de ces ETA. N'est-il pas généralement admis qu'un ETA n'est qu'une estimation et qu'aucune entreprise ne devrait faire de plans sérieux sur la base des estimations d'une autre entreprise et même si c'était le cas, l'entreprise ne peut pas blâmer AWS ou être en colère contre elle pour avoir manqué un ETA ?

Un ETA n'est pas non plus un jour spécifique. Cela peut être un mois. Un quart. Et nous devrions être d'accord avec n'importe quel ETA et d'accord s'il a été manqué.

Je pense que le fait qu'AWS ait perdu le contrat JEDI au profit d'Azure aurait dû suffire à lancer en interne des réunions de priorisation car, à première vue, cela prouve que .NET est une entreprise "au niveau de l'entreprise" et doit être traité comme tel. Au lieu de gaspiller des ressources à essayer de « poursuivre » la décision, utilisez ces ressources en interne pour donner un peu d'amour à la communauté .NET. Utilisez cela comme un moment pour redéfinir la priorité de .NET afin que la prochaine version de .NET, AWS soit au-dessus de celle-ci et montre clairement qu'ils sont prêts à démarrer.

@normj , @martincostello , et le reste des abeilles ouvrières là-bas chez AWS, travaillant très dur pour fournir une offre SOLID .NET, veuillez comprendre que ces plaintes (communautaires) ne vous concernent pas en soi, mais plutôt la culture/la politique qui dictent le mandat prioritaire qui vous a été confié vis-à-vis de .NET. Veuillez utiliser ce message pour aider à obtenir un support "au niveau de l'entreprise".

Je vois principalement cela comme une occasion manquée pour AWS de briller. Imaginez si suivre une nouvelle version LTS serait une priorité élevée. Quelle déclaration forte ce serait.

Des choses comme celle-ci font que nous, développeurs/architectes, perdons des arguments contre les décideurs non techniques lorsque nous devons décider quel cloud utiliser pour le prochain projet. De nos jours, alors qu'Azure et AWS ont des offres de coûts et de fonctionnalités pour la plupart égales, les décisions sont davantage prises sur la politique et la perception. Je n'ai rien à apporter quand ils disent "ça fait X semaines/mois après la sortie officielle et AWS n'est toujours pas prêt"

Encore une fois, comme le dit @VagyokC4 , ce n'est pas personnel contre les employés qui font le travail réel, mais plutôt un signal d'alarme pour la haute direction d'AWS.

Tous ceux qui utilisent .NET Core 3.1 Lambda peuvent envisager d'activer IL Trimming. Vous allez très probablement réduire la taille de vos fichiers zip.
https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx

est-ce que .NET core lambda 3.1 est construit à l'aide de RuntimeAPI ?
en plein air, sur github ?
si non pourquoi pas ?

Tout ce que je veux pour... La Saint-Valentin, c'est la prise en charge de lambda .net core 3.1

Tout ce que je veux pour... La Saint-Valentin, c'est la prise en charge de lambda .net core 3.1

Ne sort pas exactement de la langue, mais c'est hummable :

Je ne veux pas beaucoup pour Noël la Saint-Valentin
Il y a juste une chose dont j'ai besoin
Je me fiche des cadeaux
Sous l'arborescence AWS
Je le veux juste pour moi
Plus que tu ne pourrais jamais savoir
Réalise mon vœu oh
Tout ce que je veux pour la Saint-Valentin, c'est .NET Core 3.1 suppooooort ...

:sourire:

Microsoft inclut les licences Go Live vers la fin de leur cycle de prévisualisation lorsqu'ils n'introduiront aucun changement de rupture. À ce stade, ils offrent un support de production pour cette prochaine version. Ma recommandation serait d'attendre qu'ils publient une version avec une licence Go Live, puis de commencer à travailler sur l'outillage. Avec .NET Core 3.1, il est entré dans Preview 3 qui a été publié le 14/11. Dans ce cas, le RTM n'était même pas 3 semaines plus tard le 12/3, mais vous seriez toujours plus proche du déploiement des fonctionnalités lorsque RTM arrivera et que les clients commenceront à créer des attentes.

Juste mon 0,02 $

Tout ce que je veux pour... La Saint-Valentin, c'est la prise en charge de lambda .net core 3.1

Ne sort pas exactement de la langue, mais c'est hummable :

Je n'en veux pas beaucoup pour ~Noël~ la Saint-Valentin
Il y a juste une chose dont j'ai besoin
Je me fiche des cadeaux
Sous l'arborescence AWS
Je le veux juste pour moi
Plus que tu ne pourrais jamais savoir
Réalise mon vœu oh
Tout ce que je veux pour la Saint-Valentin, c'est .NET Core 3.1 suppooooort ...

??

+1 :)

une mise à jour sur le runtime .NET Core 3.1 pour Lambda ?

Nous commençons un nouveau projet et nous penchions fortement à utiliser Lamba pour la majorité des serveurs sans serveur, mais voir combien de temps il faut pour prendre en charge une version LTS nous fait repenser, voire changer d'architecture ou de fournisseur.

<Rant>
Il est frustrant que la politique de prise en charge d'AWS Lambda Runtime soit très stricte sur une fenêtre de 30 jours, lorsque des fonctionnalités comme celle-ci sont demandées pendant plus de 30 jours. Puis, comme par magie, AWS déploiera cette fonctionnalité et tout le monde devra se démener pour basculer vers .NET Core 3.1. Cela met la PLUPART des organisations dans une mauvaise position car il faut souvent plus d'un mois pour réparer, tester et déployer quelque chose dans un environnement de production. J'ai personnellement été un peu dans le cul par cette politique. Une fois (en raison des contraintes de ressources et d'autres priorités plus élevées), une entreprise dans laquelle j'étais a laissé échapper ce temps. Ce n'est que 3 mois plus tard que nous avons pu mettre à niveau nos Lambdas vers .NET Core 2.1. Une fois que nous avons essayé de déployer un lambda particulier avec CloudFront, quelque chose de mauvais (quoi ? qui sait parce que les journaux CF sont des ordures) s'est produit et il a dû être annulé. Sauf qu'il n'y avait pas d'environnement d'exécution vers lequel revenir. Ainsi cela LOCKED le déploiement. Nous avons immédiatement ouvert un ticket. 24 heures plus tard, nous avons reçu notre première réponse qui était "supprimer toute la pile et recommencer". Ce qui est une réponse complètement ignorante étant donné que cela aurait pris nos tables DynamoDb avec l'opération "supprimer". Nous avons été enfermés dans ce retour en arrière pendant plus de 2 semaines et demie. Finalement, nous avons eu un ingénieur de support qui a compris les technologies de conteneurs et nous a aidés à revenir en arrière, puis est resté en ligne jusqu'à ce que notre CloudFormation réussisse. Ce qui s'est bien passé, aucun changement à la première tentative. C'est en quelque sorte pourquoi je déteste maintenant CF, car il est trop capricieux à utiliser.
</Rant>

TL;DR; La politique AWS Lambda Runtime Support est désagréable à utiliser et peut vous mettre dans l'eau chaude.
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html

@CraigHead désolé pour votre expérience frustrante, mais pour être clair, quelle que soit la date de sortie de .NET Core 3.1 sur Lambda, l'environnement d'exécution .NET Core 2.1 sera pris en charge dans Lambda jusqu'au moins le 21 août 2021 en fonction du cycle de support Microsoft. Il n'y aura pas besoin de se précipiter pour convertir les fonctions 2.1 en 3.1. Je suppose que votre expérience précédente était avec le .NET Core 2.0 qui était une anomalie pour Lambda car c'était la seule version non LTS à entrer dans Lambda. Cela n'a été fait qu'en raison de problèmes majeurs avec .NET Core 1.0.

Oui, c'était la migration de .NET Core 2.0 vers .NET Core 2.1. Désolé pour le coup de gueule. 30 jours, c'est un peu serré pour certains d'entre nous. En regardant la longueur totale d'un lambda pourrait potentiellement fonctionner sans maintenance importante et QA supplémentaire.

pendant ce temps, cela se produit du côté Azure de serverless
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

Pendant ce temps, l'équipe AWS y travaille. Les commentaires sarcastiques n'aident pas
eux. Ils mettront à jour ce problème lorsqu'il sera prêt.

Le Mar. 11 Fév 2020 à 18:22, Rati Dzidziguri [email protected]
a écrit:

pendant ce temps, cela se produit du côté Azure de serverless

https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAAZVJXAAYET4F7PFFOTO3LRCLUETA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNQNMVXWWYZLOZGO71
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAAZVJQK3NBVXBZALM4V5KLRCLUETANCNFSM4JU5UTJA
.

Mon propos n'était pas de faire un commentaire sarcastique, mais de souligner que même MS a récemment annoncé la disponibilité de GA pour 3.1, j'espère donc voir AWS finaliser son travail sur le support 3.1 bientôt.
.

pendant ce temps, cela se produit du côté Azure de serverless
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

Étant donné qu'il s'agit d'un langage MS, il n'est pas surprenant qu'Azure ait battu AWS pour prendre en charge cela.

En regardant ce fil de près - j'ai hâte de mettre à niveau mes Lambdas C#.

dotnet core 3.1.0 a été publié le 03/12/2019
https://dotnet.microsoft.com/download/dotnet-core/3.1

il était disponible dans Azure le 2020-01-23
https://azure.microsoft.com/en-us/updates/azure-functions-runtime-30-is-now-available/

il nous manque un peu un mois supplémentaire par rapport à Azure

BTW, tout le développement de base .NET se fait à l'air libre sur github
Donc, être "langage MS" ne devrait pas avoir beaucoup d'effet.
Ou vous suggérez que les clients AWS utilisant dotnet sont meilleurs sur Azure :P ?

Quoi qu'il en soit, à tous ceux qui écoutent sur AWS :
nous y attendons 3.1 sur Lambda, c'est important pour nous.

BTW, tout le développement de base .NET se fait à l'air libre sur github
Donc, être "langage MS" ne devrait pas avoir beaucoup d'effet.
Ou vous suggérez que les clients AWS utilisant dotnet sont meilleurs sur Azure :P ?

Je veux dire, ce serait un peu embarrassant pour la plate-forme cloud de Microsoft de ne pas prendre en charge les nouvelles fonctionnalités de leur propre langage. Pour être honnête, je suis un peu surpris qu'il leur ait fallu un peu plus d'un mois et demi ! Un peu plus de communication interne aurait peut-être permis de sortir les deux en même temps.

Je pense qu'AWS se débrouille bien avec son support .Net, en particulier avec les packages de développement qui se connectent à leurs services tels que CloudWatch + ILogging et leur lien de configuration des paramètres SSM. Cela nous a beaucoup aidés.

J'espère voir la version 3.1 bientôt :)

Je souhaite qu'il y ait une meilleure implémentation concrète Cloudwatch de ILogger . Cela serait mieux intégré dans le ServiceCollection / ServiceProvider lors de l'utilisation du SDK Lambda. La version actuelle qui est fournie dans le contexte de la demande et la classe LambdaLogger statique est fondamentalement impossible à tester/vérifier la sortie du journal et le raccordement du .netcore ConsoleLogProvider par défaut entraîne des journaux Cloudwatch désordonnés.

Je souhaite qu'il y ait une meilleure implémentation concrète Cloudwatch de ILogger .

Avez-vous essayé https://github.com/aws/aws-logging-dotnet#aspnet -core-logging ?

À quoi voulez-vous que vos journaux ressemblent à @CraigHead ?

Nous avons utilisé Serilog & https://github.com/structured-log/structured-log dans le passé pour générer des journaux de console agréables ainsi que des journaux basés sur JSON qui ont été importés dans Seq. https://datalust.co/ c'était le meilleur moyen pour nous d'obtenir des journaux centraux dans un très bon format.

@CraigHead Amazon.Lambda.Logging.AspNetCore est notre implémentation pour intégrer la journalisation de Lambda dans IServiceCollection. Cette bibliothèque ne fonctionne-t-elle pas pour vous.

Je ne recommanderais pas le package AWS.Logger.AspNetCore de ttps://github.com/aws/aws-logging-dotnet#aspnet -core-logging pour Lambda. Cette bibliothèque utilise un thread d'arrière-plan pour envoyer les journaux vers CloudWatch Logs. L'utilisation d'un thread d'arrière-plan comme celui-ci ne fonctionne pas bien avec Lambda qui gèle l'environnement de calcul Lambda dès que le gestionnaire de fonction revient, ce qui signifie que le thread d'arrière-plan peut ne pas avoir la possibilité de vider les messages en file d'attente.

Je ne savais pas à ce sujet. Merci pour le tuyau!
Je faisais référence au Amazon.Lambda.Core.LambdaLogger dans le SDK.
Je vais certainement vérifier ce package ( Amazon.Lambda.Logging.AspNetCore ).

https://docs.aws.amazon.com/lambda/latest/dg/csharp-logging.html

@clearwaterstream
Dans lambda-land AFAIK, aucun événement ne vous informera que l'instance actuelle arrêtera le traitement ou sera terminée, donc votre suggestion laissera toujours les événements de journal mis en mémoire tampon non vidés (perdus).

Merci de ne pas détourner ce fil pour d'autres besoins.
Ce fil a été créé pour donner des informations sur la disponibilité de .NET Core 3.1 sur AWS Lambda.
Et pour faire savoir à AWS que nous sommes là et que nous attendons.

L'outil de test lambda sera-t-il inclus dans la version 3.1 ? https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

C'est mon intention. Le travail est en cours dans le mock-testtool-31 . La grande amélioration de la branche 3.1 est que le code Lambda de l'utilisateur s'exécute désormais dans un AssemblyLoadContext séparé, ce qui devrait résoudre de nombreux conflits de version que les utilisateurs ont avec la version actuelle. J'envisage de reconduire la fonctionnalité AssemblyLoadContext dans la version 2.1.

En remarque. J'ai débattu de la conversion de l'interface utilisateur nue en une application Blazor côté serveur. Est-ce que quelqu'un avec plus d'expérience Blazor a des commentaires sur si c'est une bonne ou une mauvaise idée ?

En remarque. J'ai débattu de la conversion de l'interface utilisateur nue en une application Blazor côté serveur. Est-ce que quelqu'un avec plus d'expérience Blazor a des commentaires sur si c'est une bonne ou une mauvaise idée ?

Tout ce qui est Blazor à ce stade est une bonne idée, surtout pour ceux d'entre nous qui utilisent DotNet !

"Bare bones UI" - il s'agit d'une autre application, non connectée à .NET Core 3.1 Lambdas ?
BTW, je ne me soucie pas du tout du blazor

@petarrepac Cela faisait référence à l'outil de test AWS .NET Mock Lambda que nous avons expédié pour aider à déboguer les fonctions Lambda .NET Core 2.1. Voici le post pour référence https://aws.amazon.com/blogs/developer/debugging-net-core-aws-lambda-functions-using-the-aws-net-mock-lambda-test-tool/

Je suis en train de mettre à jour l'outil pour .NET Core 3.1.

@normj
ah, je n'ai pas compris, merci
c'est intéressant de penser que nous n'avons jamais eu besoin d'un tel outil

de notre point de vue, lambda est un AspNetCore HttpApi barebone que vous pouvez appeler localement et tester localement
la seule différence est le fichier/classe du point d'entrée qui fait moins de 50 lignes de code
De plus, beaucoup de choses ne peuvent être correctement testées que lorsqu'elles sont déployées sur AWS :

• autorisations
• forme des événements JSON reçus et contexte
• ...
  donc, une combinaison de :
• bons tests unitaires/d'intégration exécutés localement
• test http local
• facile à déployer pour tester l'environnement aws
  peut aller loin

ou il me manque un scénario évident ?

@petarrepac C'est l'un des grands avantages de l'utilisation du pont ASP.NET Core, c'est qu'il est vraiment facile à exécuter localement. Je suis d'accord que la meilleure pratique consiste à utiliser des tests unitaires/d'intégration, mais il y a souvent des besoins pour des tests ad hoc rapides de la logique d'application et c'est à cela que cet outil est bon.

Merci @normj. En ce qui concerne Blazor, cela pourrait être une belle touche. Pour le cas d'utilisation de notre équipe, au moins, cela serait probablement sous-utilisé.

Nous ne sommes dans l'interface utilisateur que suffisamment longtemps pour envoyer une charge utile, puis parcourir le code dans VS.

Vous pouvez certainement réaliser plusieurs fonctions lambda à partir d'une base de code à l'aide du programme d'amorçage Lambda et de la fonction d'exécution personnalisée.

J'ai une suite de 16 lambdas qui sont déployés à partir d'une seule application, plutôt qu'un « monolithe ».

Ceci est réalisé en utilisant la variable d'environnement _handler pour choisir la méthode à utiliser au moment de l'exécution, plutôt que le mappage un-à-un codé en dur indiqué dans l'exemple de code de l'article de blog.

Je le considère comme une application de console qui reçoit un commutateur qui lui indique quelle action « devenir » au démarrage.

@martincostello

J'ai du mal à m'en sortir d'après vos explications. J'ai environ 20 fonctions Lambda dans mon Functions.cs qui sont liées aux définitions correspondantes dans mon serverless.template. Je comprends que vous passeriez une variable d'environnement avec chaque définition pour indiquer quelle fonction appeler. La plupart de ces fonctions sont de la signature :

public APIGatewayProxyResponse ThisLambdaFunction (demande APIGatewayProxyRequest, contexte ILambdaContext)
{

Comment ajouter la prise en charge de différentes signatures de fonction lambda, si j'ai d'autres fonctions qui prennent des arguments différents (autres que APIGatewayProxyRequest ) et des types de retour différents ?

Veuillez ne pas faire dérailler le fil.

@twopointzero J'ai passé des jours sur Google à rechercher une solution pour exécuter plusieurs fonctions lambda à l'aide du projet d'exécution personnalisé .NET Core 3.1. Il n'y a plus de fil de discussion pertinent sur Internet et je réponds à un post existant qui a donné une lueur d'espoir qu'il existe une solution à mon problème.

L'absence de prise en charge native de .NET Core 3.1 dans AWS rend la vie difficile. Nous devons mettre à niveau vers 3.1 afin de passer à la dernière EntityFramewore Core 3.1.2, qui résout les problèmes que nous constatons avec le regroupement de connexions dans Aurora (PostgresSQL).

@normj Je comprends parfaitement la position sans ETA mais pouvez-vous me dire si nous sommes proches ? < 30 jours ?

@antsaia Avec respect, votre commentaire concernait le déploiement d'un monolithe distribué à l'aide de la prise en charge d'exécution personnalisée, et non la prise en charge d'AWS Lambda pour .NET Core 3.1. Si vous ne trouvez pas de fil plus pertinent sur Internet, je vous prie de bien vouloir en créer un plutôt que de le faire dérailler.

Afin de ne pas faire dérailler ce fil moi-même, ceci est mon dernier commentaire sur la question.

@normj existe-t-il des ressources disponibles (blog, forum, etc.) où nous pouvons obtenir des informations sur l'état de la mise en œuvre de la prise en charge de .net core 3.1 ?

Je visite cette page quotidiennement dans l'espoir d'obtenir de nouvelles informations mais évidemment il n'y a pas assez d'informations (car elle n'est pas destinée à cet usage). Cela rendrait les choses beaucoup plus faciles si nous avions une sorte de mise à jour de base afin que nous puissions planifier à l'avance.

Comme beaucoup ici, nos plans pour fournir des fonctionnalités dépendent beaucoup de si nous pouvons utiliser 3.1 ou si nous devons le développer en utilisant 2.1. Dans mon cas, 3.1 fournira un support pour System.Draw et cela a un impact majeur sur la fonctionnalité sur laquelle je dois travailler.

Tout ce que je veux pour... la Saint-Patrick, c'est la prise en charge de lambda .net core 3.1

@liam-sage tout ce que j'ai pu trouver, ce sont quelques messages sur le forum amazon indiquant qu'il serait prêt au premier trimestre 2020. https://forums.aws.amazon.com/thread.jspa?threadID=313806

@liam-sage tout ce que j'ai pu trouver, ce sont quelques messages sur le forum amazon indiquant qu'il serait prêt au premier trimestre 2020. https://forums.aws.amazon.com/thread.jspa?threadID=313806

Cela signifie qu'il doit être mis en ligne en mars. J'attends.

Bonjour, je sais que ce n'est pas tout à fait approprié, mais vous pouvez mettre à jour vos propres lambdas vers dotnetcore 3.1. En attendant, pendant que vous attendez, je vous suggère de créer beaucoup de lambdas pour écrire votre propre modèle dotnetcore. Je l'ai fait pour le mien. Je voulais m'assurer de ne pas perdre des heures avec du code passe-partout. Un exemple de modèle peut être trouvé ici .

Et Vincent, comment on l'héberge là-bas ? en utilisant un environnement d'exécution personnalisé ?
Le jeu. 5 mars 2020 à 19:40 Vincent van der Walt <
[email protected]> a écrit :

Bonjour, je sais que ce n'est pas tout à fait adapté mais vous pouvez vous procurer vos propres lambdas
mis à jour vers dotnetcore 3.1. En attendant, pendant que vous attendez, je suggérerais
si vous créez beaucoup de lambdas pour écrire votre propre modèle dotnetcore. J'ai fait
que pour le mien. Je voulais m'assurer de ne pas avoir à perdre des heures avec
code passe-partout. Un exemple de modèle peut être trouvé ici
https://github.com/vincentvanderwalt/aws-lambda-dotnetcore-3-template .

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AGIDH4OWUT7Y3HR3O5KARBDRF62V3A5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBJGcomKLNMVX5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBJGcomKLNMVX5
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AGIDH4PLKFSDLNBX2QVMG63RF62V3ANCNFSM4JU5UTJA
.

Oui, il utilise le runtime personnalisé.

Vous pouvez l'exécuter localement sur votre ordinateur ou le déployer sur aws.

F5 pour local et dotnet lambda deploy-serverless pour le déploiement vers aws

Le fichier readme explique comment installer le modèle sur votre machine locale (c'est un modèle dotnetcore)

Les environnements d'exécution personnalisés sont sympas, mais j'attends toujours la prise en charge complète d'AWS pour .Net Core 3.1 pour que les lambdas les utilisent dans des environnements de production 😄

Chaque fois que je vois cela dans ma boîte de réception, je l'ouvre avec impatience pour voir si @normj a
annoncé n'importe quoi pour trouver une publication qui est au moins un peu décalée
sujet. Quelqu'un d'autre a demandé aux autres de ne pas détourner le fil et cela n'a pas
travaillé. Quelqu'un peut-il verrouiller le fil jusqu'à ce que quelqu'un soit prêt à annoncer le
sortie de la prise en charge 3.1 ?

Le vendredi 6 mars 2020 à 7h13 bartoszsiekanski [email protected]
a écrit:

Les environnements d'exécution personnalisés sont sympas, mais j'attends toujours la prise en charge complète d'AWS
pour .Net Core 3.1 pour les lambdas pour les utiliser dans des environnements de production 😄

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAVUT3SNDR4L2ZL5J4KQYDDRGDSHBA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMHJCOMKEOZDNVW074A5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMHJCOMKEOZDNMVW07
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAVUT3TBH3NIBMGB54EFCR3RGDSHBANCNFSM4JU5UTJA
.

Veuillez créer des problèmes distincts pour toute autre chose que de discuter de la prise en charge de .NET Core 3.1. Puis-je fermer ce problème jusqu'à ce que nous ayons plus de nouvelles @normj ?

@ hounddog22030 Je n'avais pas réalisé que j'étais en

Si AWS prend en charge l'option --self-contained dans la commande dotnet lambda package, les fonctions lambda doivent être exécutables quelle que soit leur version du SDK. droit? Pourquoi ne pas le faire au lieu d'ajouter la prise en charge de chaque version de .NET Core ?

Si AWS prend en charge l'option --self-contained dans la commande dotnet lambda package, les fonctions lambda doivent être exécutables quelle que soit leur version du SDK. droit? Pourquoi ne pas le faire au lieu d'ajouter la prise en charge de chaque version de .NET Core ?

Vous venez de décrire la fonctionnalité d'exécution personnalisée lambda

@aussieare Cela fonctionne bien, mais le package autonome inclut .Net Core lui-même, qui ajoute généralement jusqu'à au moins 40 Mo (zippés) pour un site Web - ne laissant pas beaucoup de place pour l'application et les dépendances elles-mêmes.

Lorsque vous utilisez la même version de .NET core, le runtime personnalisé est également plus lent (démarrages à froid) que le runtime natif. 3.1 ajoute de nombreuses améliorations de performances, vous pouvez donc vous attendre au même niveau de performances entre 3.1 personnalisé entièrement optimisé et 2.1 natif. J'espère que 3.1 native apportera des améliorations significatives.

Le premier trimestre se terminera dans 4 jours, mais il semble que nous ne verrons pas 3.1 en lambda.
J'espère que tous les membres de l'équipe sont en sécurité en cette période de pandémie et j'espère voir cette version au deuxième trimestre.

Ne désespérez pas, il nous reste quelques jours ! Nous sommes tous à peu près prêts à attendre les derniers déploiements et autres activités de dernière minute. Gardez à l'esprit que nous connaissons tous les logiciels et qu'il pourrait y avoir des problèmes de dernière minute.

En fait, je prévois de commencer bientôt le déploiement des nouvelles mises à jour de l'outillage client pour m'assurer que tout est disponible une fois l'environnement d'exécution ouvert. Donc, si vous voyez de nouvelles mises à jour du package NuGet sortir, ne supposez pas que le runtime est là. Attendez que l'article du blog soit publié et je publierai une mise à jour ici.

C'est une nouvelle fantastique. Merci @normj

Dans l'attente de la publication et de la publication du blog.

Ne désespérez pas, il nous reste quelques jours ! Nous sommes tous à peu près prêts à attendre les derniers déploiements et autres activités de dernière minute. Gardez à l'esprit que nous connaissons tous les logiciels et qu'il pourrait y avoir des problèmes de dernière minute.

En fait, je prévois de commencer bientôt le déploiement des nouvelles mises à jour de l'outillage client pour m'assurer que tout est disponible une fois l'environnement d'exécution ouvert. Donc, si vous voyez de nouvelles mises à jour du package NuGet sortir, ne supposez pas que le runtime est là. Attendez que l'article du blog soit publié et je publierai une mise à jour ici.

Votre patience face à l'attitude de ce fil est plus qu'impressionnante. Merci d'avoir travaillé là-dessus !

@normj heureux d'assister à tous les tests que vous souhaitez effectuer avant la publication ;)

Encore 2 jours et croisons les doigts.

Et c'est parti avec 13 heures restantes dans le quart 😅

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

Merci à tous pour votre patience. @raRaRa Je vous laisse l'honneur de clore ce numéro.

Super

Le mardi 31 mars 2020, 20:06 Norm Johanson, [email protected] a écrit :

Et c'est parti avec 13 heures restantes dans le quart 😅

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

Merci à tous pour votre patience. @raRaRa https://github.com/raRaRa
Je vous laisse l'honneur de clore ce numéro.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-606785798 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AGUX3OUR6LN5CERIBTDHXP3RKIWLVANCNFSM4JU5UTJA
.

Merci!!!!

Et.... Désabonnez-vous :-)

Merci à tous les participants !!!

Merci!

Et c'est parti avec 13 heures restantes dans le quart 😅

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

Merci à tous pour votre patience. @raRaRa Je vous laisse l'honneur de clore ce numéro.

Bon travail!

C'est AWS bébé. C'est AWS !!!
Peu importe ce qui se passe, à la fin, ils le font.

Merci beaucoup l'équipe !!!

Bonne nouvelle et merci beaucoup @normj !!! Au risque de paraître stupide et/ou gourmand, cela signifie-t-il aussi intrinsèquement Powershell 7 ? Juste une double vérification......

Excellent travail @normj et tout le monde chez AWS ! ??

Voici le lien vers le blog pour ceux qui défilent vers le bas
https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

génial, merci mille fois pour l'ajout de la prise en charge de dotnet core 3.1 !!!

@andyKalman Pas encore sur PowerShell 7. Je fais quelques retouches finales sur le module AWSLambdaPSCore, puis je publierai la version 2.0.0 d'AWSLambdaPSCore dans la galerie.

J'apprécie la réponse rapide @normj . J'ai vu le #607 après coup si bon de voir que cela semble être un suivi rapide. Y a-t-il un autre problème à suivre pour que je puisse arrêter les commentaires ici ? :) Merci encore.

Félicitations!
Et merci à l'équipe AWS et .NET !
Très appréciée.

Merci à tous ceux qui ont contribué à ce que cela se produise ! C'est une sortie énorme et cela montre qu'il y a eu beaucoup de travail acharné ! Joli! ??

Merci !! : clap:: clap:: tada:: tada:

Félicitations les gars, hâte de mettre à niveau.

Merci!

Travail impressionnant, désireux de mettre à niveau ces lambdas.

Bon travail! Merci @normj 👏 👏

Super travail d'équipe !

Désireux de sauter sur les travailleurs Lambda avec dotnet 3.1 Async Streams + abonnements AWS AppSync/GraphQL.
Équipe AWS, merci beaucoup !

OMG, les gars, vous les règles ! Incroyable! Waouh ! ??

MERCI!

@andyKalman J'ai sorti la version 2.0.0 du module AWSLambdaPSCore qui utilise désormais PowerShell 7. Je prévois de publier un article de blog sur le support PS7, mais il agit de la même manière que le support PowerShell 6 existant n'utilise que 7.

@andyKalman J'ai sorti la version 2.0.0 du module AWSLambdaPSCore qui utilise désormais PowerShell 7. Je prévois de publier un article de blog sur le support PS7, mais il agit de la même manière que le support PowerShell 6 existant n'utilise que 7.

La nouvelle version d'AWSLambdaPSCore met-elle à jour certaines des configurations de mes fonctions Lambda existantes si je les publie avec la nouvelle version ? Comme est-ce qu'il le dirigera vers dotnet3.1 et ps7?

@tr33squid Oui si vous déployez avec 2.0.0, il utilisera .NET Core 3.1 et PS7

Merci beaucoup et bon travail à l'équipe AWS !!

Salut à tous,

Je travaille activement à la prise en charge de .NET Core 3.1 dans Lambda. Cela prend un certain temps car Microsoft a effectué beaucoup de travail sur la façon dont ils créent le runtime. Je travaille sur l'intégration de ces changements pour vous apporter un runtime natif.

Merci à l'équipe principale AWS-Lambda .NET

Salut,
J'obtiens cette erreur lorsque j'essaie d'exécuter AWS-Lambda
Il n'a pas été possible de trouver une version de framework compatible.
Le framework spécifié 'Microsoft.AspNetCore.App', version '3.1.0' n'a pas été trouvé.
Aucune suggestion ??

Salut,
J'obtiens cette erreur lorsque j'essaie d'exécuter AWS-Lambda
Il n'a pas été possible de trouver une version de framework compatible.
Le framework spécifié 'Microsoft.AspNetCore.App', version '3.1.0' n'a pas été trouvé.
Aucune suggestion ??

Vous devez installer le SDK 3.1.0.

Je pense que Microsoft.AspNetCore.App doit être supprimé de votre projet
dépendances, plus nécessaires pour Core 3.1.0, j'ai dû le supprimer pour
construire et déployer le service que j'ai mis à niveau à partir de 2.1.

Le ven 24 avril 2020 à 03h24 Gregory Lyons [email protected]
a écrit:

Salut,
J'obtiens cette erreur lorsque j'essaie d'exécuter AWS-Lambda
Il n'a pas été possible de trouver une version de framework compatible.
Le framework spécifié 'Microsoft.AspNetCore.App', version '3.1.0' était
pas trouvé.
Aucune suggestion ??

Vous devez installer le SDK 3.1.0.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-618850277 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA
.

--
Meilleur,
George

Georges Taskos
Architecte de solutions senior

WeAre8
230, avenue du Parc, 3e étage. Ouest
New York, État de New York 10169
(917) 717-9067
weare8.com

Entrée privée,
71, avenue Vanderbilt
3ème étage

Je pense que Microsoft.AspNetCore.App devrait être supprimé des dépendances de votre projet, il n'est plus nécessaire pour Core 3.1.0, j'ai dû le supprimer pour créer et déployer le service que j'ai mis à niveau à partir de 2.1.
…
Le ven 24 avril 2020 à 03h24 Gregory Lyons @ . * > a écrit : Salut, j'obtiens cette erreur en essayant d'exécuter AWS-Lambda Il n'a pas été possible de trouver une version de framework compatible. Le framework spécifié 'Microsoft.AspNetCore.App', version '3.1.0' n'a pas été trouvé. Aucune suggestion ?? Vous devez installer le SDK 3.1.0. — Vous recevez ceci parce que vous êtes abonné à ce fil. Répondez directement à cet e-mail, consultez-le sur GitHub < #554 (commentaire) > ou désabonnez-vous https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA .
-- Meilleur, George George Taskos Architecte de solutions senior WeAre8 230 Park Avenue, 3e étage. West New York, NY 10169 (917) 717-9067 weare8.com Entrée privée, 71 Vanderbilt Ave 3rd Floor

Merci pour votre réponse,
En fait, cette erreur était due à mon erreur stupide. J'ai oublié de supprimer le runtime : dotnetcore2.1 dans mon serverless.yml. Maintenant problème résolu.

Quelqu'un fait-il des benchmarks/comparaisons mis à jour à ce sujet ? Tout ce que je peux trouver, ce sont des anciens avec un runtime personnalisé.

Quelqu'un fait-il des benchmarks/comparaisons mis à jour à ce sujet ? Tout ce que je peux trouver, ce sont des anciens avec un runtime personnalisé.

En voici une bonne.
https://medium.com/@zaccharles/a -close-look-at-net-core-3-1-on-aws-lambda-9ccec4dd96be

De plus, mon expérience personnelle de mise à jour d'un lambda complexe 2.1 à 3.1 sur une taille lambda de 512 Mo a vu presque exactement les mêmes performances (démarrage à froid et à chaud). Les lambda 2.1 et 3.1 utilisent la couche lambda, la publication optimisée, newtonsoft (pourrait voir une amélioration des performances avec Microsoft json en 3.1), la compilation à plusieurs niveaux et RTR pour 3.1.

D'après mes métriques, il semble gagner de légères performances avec l'exécution de dotnet 3.1, mais perdre des performances sur Amazon Linux 2 et l'initialisation de dotnet 3.1. (2.1 utilise Amazon Linux 1.) Faire des gains un lavage.