Aws-lambda-dotnet: .NET Core 3.1 (LTS) wurde veröffentlicht

Es ist ein LTS und wird unterstützt. Es wird nur einige Zeit dauern, bis .NET Core 3.1 für Lambda bereit und bereitgestellt ist.

Es ist ein LTS und wird unterstützt. Es dauert nur eine Weile, bis .NET Core 3.1 für Lambda bereit und bereitgestellt ist.

Wenn ich etwas tun kann, um zu helfen, lass es mich wissen.

Wird es eine Beschleunigung für die Kaltstartzeit geben?

.NET Core 3.1 verfügt über einige Funktionen wie die AOT-Kompilierung

• VeröffentlichenReadyToRun
• VeröffentlichenTrimmed

@normj sollten die Leute dieses Problem für Updates abonnieren oder gibt es ein anderes .NET Core 3.1-Problem, dem wir folgen sollten, um Fortschritte zu

Wir können dieses Problem verwenden, um Updates zu verfolgen. Leider werde ich wahrscheinlich nicht in der Lage sein, viele Statusaktualisierungen bereitzustellen, bis es draußen ist.

Wird es eine Beschleunigung für die Kaltstartzeit geben?

.NET Core 3.1 verfügt über einige Funktionen wie die AOT-Kompilierung

• VeröffentlichenReadyToRun
• VeröffentlichenTrimmed

Falls die Antwort für den Kommentar ja lautet, ist es dann möglich, das "kompilierte Lambda" in einer lokalen Umgebung auszuführen und zu testen? Ich würde eifrig eine Linux-Umgebung dafür einrichten :)

Irgendein Update hier?

@rati-dzidziguri

Wie oben von @normj

Wir können dieses Problem verwenden, um Updates zu verfolgen. Leider werde ich wahrscheinlich nicht in der Lage sein, viele Statusaktualisierungen bereitzustellen, bis es draußen ist.

@beeradmoore
Meine Frage bezog sich auf ETA. Das wäre hilfreich, die ETA dafür zu kennen, da wir uns entsprechend vorbereiten könnten.

@rati-dzidziguri Amazon gibt selten seine ETA bekannt, wenn es um Veröffentlichungen geht.

@rati-dzidziguri Ich verstehe und schätze Sie, dass Sie eine ETA wünschen, damit Sie entsprechend planen können. In Wirklichkeit geben wir aus diesem Grund im Allgemeinen keine ETA, weil wir uns wirklich bemühen, keine Versprechungen zu machen, von denen wir nicht 100% sicher sind, dass wir sie halten können. Ich würde es hassen, Ihnen eine ETA zu geben, und Sie erstellen Ihre Roadmap auf dieser Grundlage und wir vermissen diese ETA, von der Sie erwartet hatten, dass sie alle Ihre Pläne durcheinander bringt.

Denn jetzt , wenn Sie benötigen .NET Core - 3.1 - Funktionen wirklich dann schlage ich .NET - Core 3.1 als Lambda Benutzerdefinierte Runtime verwendet , die erklärt wird hier (außer Änderung Referenzen von .NET - Core 3.0 auf .NET - Core 3.1). Wenn dann die native .NET Core 3.1-Unterstützung verfügbar ist, haben Sie eine sehr einfache Migration, bei der Sie einige Einstellungen Ihrer Lambda-Funktion ändern müssen.

@normj Ein Grund dafür, dass ich die benutzerdefinierte Laufzeitfunktion nicht mit der Klasse 'LambdaEntry' verwenden kann, ist der Aspekt der 'monolithischen Architektur' des Implementierungsansatzes. Jede API-Anfrage kommt durch das einzige Lambda-Eintrag und wird an die Controller des ASP .net-Projekts "verteilt", was die benutzerdefinierte Laufzeitstruktur beabsichtigte, was definitiv praktisch ist, aber für Fälle wie ich es wünsche, strukturelle Nachteile mit sich bringt. Ich möchte, dass jede Befehls-/Abfrageanforderung jeweils zu Lambda wird. Seitdem kann ich eine Skalierbarkeit bei der Verwaltung von Bereitstellungspaketen erhalten, sodass ich einige Funktionen aufteilen und Codes verwalten kann, wann immer ich möchte.
Aus diesem Grund warte ich darauf, dass die offizielle Laufzeit unterstützt wird, damit ich ein Bündel von 'Einzelzweck-Lambdas' mit SAM erstellen kann, das in einer Vorlage mit der Konfiguration 'runtime : .netcore 3.1' geschrieben ist.

Bitte gebt mir einen Rat, wenn ich falsch liege :)

Mit dem Lambda Bootstrapper und der benutzerdefinierten Laufzeitfunktion können Sie definitiv mehrere Lambda-Funktionen aus einer Codebasis erreichen.

Ich habe eine Suite von 16 Lambdas, die von einer Anwendung und nicht von einem „Monolithen“ bereitgestellt werden.

Dies wird erreicht, indem die Umgebungsvariable _handler wird, um die Methode auszuwählen, die zur Laufzeit verwendet werden soll, und nicht die hartcodierte Eins-zu-Eins-Zuordnung, die im Beispielcode des Blogposts gezeigt wird.

Ich stelle es mir als Konsolen-App vor, die einen Schalter erhält, der ihr mitteilt, welche Aktion beim Start ausgeführt werden soll.

@martinkostello
Vielen Dank für den netten Vorschlag! Ich kann mir vorstellen, wie Ihr Fall aussehen könnte. Möglicherweise haben Sie die Switch-Logik in der Main- oder Startup-Klasse platziert, damit ihre Funktionalität in der ersten Phase der Laufzeit bestimmt werden kann. Und es kann natürlich das „nur monolithische“ Problem lösen. Sehr cleverer Ansatz :)

Trotzdem muss ich an eine (wenn nicht viele) Überlegung denken, besonders wenn ich mir vorstelle, im Team zu arbeiten. Durch die Verwendung einer benutzerdefinierten Laufzeit und das Bestimmen der "funktionalen Identität" beim Start wird die Möglichkeit von SAM beseitigt. Als einfaches Beispiel für uns kann das API-Gateway nicht während der Bereitstellung eines Lambda definiert werden, was bedeutet, dass wir eines dafür manuell generieren müssen.
Ich weiß, dass ich hier übertreibe, weil wir mit dem Bootstrap-Skript eine SAM-ähnliche Konfiguration vornehmen können, wie das aws-Tutorial erklärt wurde . Aber es wird uns nicht vollständig zufriedenstellen, da es ein Linux-Skript verwendet, was bedeutet, dass
(1) Es kann für Neuankömmlinge peinlich sein und manchmal wird es zu einer Lernkurve.
(2) es wird den Vorteil der Aussagekraft des serverlosen Templates verwerfen, da es sich buchstäblich um ein Skript und nicht um ein Dokument handelt.

Ich denke, das serverlose Template funktioniert als Semi-Dokument dessen, wie der Server aussieht und wie er funktioniert, das nicht nur innerhalb eines Entwicklungsteams, sondern sogar mit einigen aufschlussreichen Nicht-Technikern geteilt wird. und SAM ist ein gut definiertes Konzept, das es in naher Zukunft ermöglichen wird, durch abstrakte Darstellungen einer Anwendung von einem anderen Team mit völlig anderen Sprachen und Plattformen wiederverwendet zu werden. Diese Aspekte motivieren mich immer noch unbestreitbar, bei der Verwendung der 'Serverless Template'-Funktion zu bleiben.

Ein paar schöne Termine für die Veröffentlichung, 25. Dezember, 1. Januar fallen mir ein ;)

Ich wünschte, ich könnte Ihnen allen .NET Core 3.1 Lambda Runtime zu Weihnachten schenken, aber ich denke, 2020 wird ein aufregendes Jahr für .NET und AWS.

Ich wünschte, ich könnte Ihnen allen .NET Core 3.1 Lambda Runtime zu Weihnachten schenken, aber ich denke, 2020 wird ein aufregendes Jahr für .NET und AWS.

Keine Sorge, genießt die Feiertage! Ich kann es kaum erwarten zu sehen, was Sie 2020 für uns haben! :)

Warten auf native Lambda-Unterstützung auf .NetCore3.1

Es gibt eine Beschränkung der Festplattengröße für Lambda-Funktionen. Ich denke, es sind 250 MB und wenn wir die benutzerdefinierte Laufzeit verwenden, müssen wir alle asp.net-Kernassemblys zusammen mit unserer App senden. Ich habe dieses Limit erreicht, als AWS mein Zip-Paket entpackt hat. Ich musste etwas aufräumen, um den von meiner App verwendeten Speicherplatz zu reduzieren. Wenn die native Unterstützung verfügbar ist, müssen wir unsere App nicht mit den Assemblys von .core verpacken.

Gibt es eine Schätzung, wann wir mit der Veröffentlichung rechnen können?

Wir warten mit dem Upgrade auf .Net Core 3.1, bis es native Unterstützung dafür gibt.

Gibt es eine Schätzung, wann wir mit der Veröffentlichung rechnen können?

Wir warten mit dem Upgrade auf .Net Core 3.1, bis es native Unterstützung dafür gibt.

Wenn Sie zurückgehen und die Antworten lesen, lesen Sie von normj, dass sie keine Schätzungen abgeben.

Wenn Sie zurückgehen und die Antworten lesen, lesen Sie von normj, dass sie keine Schätzungen abgeben.

Mmmh normalerweise - ja. Aber wenn genug Leute mit Pitchgabeln auftauchen, wird vielleicht ein Hinweis auf einen Veröffentlichungstermin gegeben, um die Unruhen zu unterdrücken :grin:

Ich erinnere mich, dass AWS vor einiger Zeit lange Zeit damit verbrachte, die nativen 2.1-Images vorzubereiten. Sie sagten, dass sie den Prozess neu gestaltet haben, um die Bereitstellung zukünftiger Versionen einfacher und schneller zu machen. Geben Sie NetCore 3.1 ein und fast zwei Monate später ist es immer noch nicht verfügbar :(

Sie wissen, dass Azure dieses 3.1-Image am ersten Tag zur Verfügung hatte. Mir wird langsam klar, warum sich die US-Regierung für Azure als Cloudanbieter für JEDI entschieden hat.

Wir haben gerade grünes Licht von unseren Stakeholdern bekommen, um Azure als unseren primären Anbieter ins Visier zu nehmen und AWS als Backup zu verlassen. Mit solchen albernen Verzögerungen sind wir sicher nicht die einzigen.

Ich erinnere mich, dass AWS vor einiger Zeit lange Zeit damit verbrachte, die nativen 2.1-Images vorzubereiten. Sie sagten, dass sie den Prozess neu gestaltet haben, um die Bereitstellung zukünftiger Versionen einfacher und schneller zu machen. Geben Sie NetCore 3.1 ein und fast zwei Monate später ist es immer noch nicht verfügbar :(

Sie wissen, dass Azure dieses 3.1-Image am ersten Tag zur Verfügung hatte. Mir wird langsam klar, warum sich die US-Regierung für Azure als Cloudanbieter für JEDI entschieden hat.

Wir haben gerade grünes Licht von unseren Stakeholdern bekommen, um Azure als unseren primären Anbieter ins Visier zu nehmen und AWS als Backup zu verlassen. Mit solchen albernen Verzögerungen sind wir sicher nicht die einzigen.

Ich stimme mit Ihnen ein. Meine Organisation erlaubt keine benutzerdefinierte Laufzeit und wir bleiben bei 2.1 hängen. Wenn es um EF & Postgres sowie räumliche Operationen geht, ist es zu viel Schmerz. Darauf haben wir gewartet. Schade, dass es noch nicht fertig ist.

Ich erinnere mich, dass AWS vor einiger Zeit lange Zeit damit verbrachte, die nativen 2.1-Images vorzubereiten. Sie sagten, dass sie den Prozess neu gestaltet haben, um die Bereitstellung zukünftiger Versionen einfacher und schneller zu machen. Geben Sie NetCore 3.1 ein und fast zwei Monate später ist es immer noch nicht verfügbar :(

Sie wissen, dass Azure dieses 3.1-Image am ersten Tag zur Verfügung hatte. Mir wird langsam klar, warum sich die US-Regierung für Azure als Cloudanbieter für JEDI entschieden hat.

Wir haben gerade grünes Licht von unseren Stakeholdern bekommen, um Azure als unseren primären Anbieter ins Visier zu nehmen und AWS als Backup zu verlassen. Mit solchen albernen Verzögerungen sind wir sicher nicht die einzigen.

Verwendet JEDI .NET Core, um davon auszugehen, dass sich die Regierung deshalb für Azure entschieden hat?

Hallo allerseits,

Ich arbeite aktiv daran, die Unterstützung für .NET Core 3.1 in Lambda bereitzustellen. Es dauert einige Zeit, da von Microsoft viel Arbeit geleistet wurde, um die Laufzeit zu erstellen. Ich arbeite daran, diese Änderungen zu integrieren, um Ihnen eine native Laufzeitumgebung zu bieten.

@assyadh Danke! Ich glaube nicht, dass die Verzögerungen "albern" sind; Tatsächlich würde ich eher auf eine solide funktionierende Version warten. Ich finde es toll, dass AWS Lambda .NET Core unterstützt, und ich weiß es zu schätzen, dass Sie es wie versprochen weiterhin unterstützen.

Ich verstehe den Drang nicht. Es ist nicht so, dass wir gerade keine LTS-Umgebung haben.

Natürlich wollen wir die neuen Spielzeuge nutzen, aber das .NET-Team bei AWS hat nur eine feste Menge an Ressourcen und kann nicht alles auf einmal tun.

Außerdem sehne ich mich nicht danach, die Laufzeit aller Funktionen überstürzen und aktualisieren zu müssen, aus Angst, nicht mehr gewartet zu werden.

Gut für dich @Kralizek, aber deine Situation gehört dir und repräsentiert nicht andere. Es ist jetzt nicht wirklich "neues Spielzeug", oder? .NET Core 3.x (und ASP.NET Core) weist in vielerlei Hinsicht erhebliche Verbesserungen gegenüber 2.x auf, und Early Adopters sind daran interessiert, diese zu übernehmen und zu nutzen. Wie @JamesQMurphy sagt, würden wir es auch vorziehen, dass die Veröffentlichung solide ist.

Ich freue mich auf deine Arbeit @assyadh.

"Ich verstehe den Drang nicht."

Wir können kein gemeinsam genutztes .NET Core 3.1 in einer .NET Core 2.1-Lambda-Funktion verwenden, tatsächlich können wir nicht einmal gemeinsam genutzten .NET Core 2.2-Code in einer .NET Core 2.1-Lambda-Funktion verwenden freigegebene Komponenten in .NET Core 2.1, damit sie in der Funktion unterstützt werden.

Können Ihre freigegebenen Komponenten in netstandard20 kompiliert werden? Dann kannst du sie in netcore2&3 teilen

Obwohl dieser Thread spezifisch für .NET 3.1 ist, bin ich mir sicher, dass genau diese Konversation erneut abgespielt wird, wenn .NET 5 eintrifft (oder 6, wenn dies der nächste LTS sein wird).

Während einige konkrete Beispiele angeführt wurden, wo dies nicht möglich ist (z. B. Code-ZIP-Datei zu groß, Unternehmensrichtlinie), können Sie _im Allgemeinen_, wenn Sie in Zukunft den „neuesten und besten“ .NET Core verwenden möchten, dies mit a wenig Refactoring und das benutzerdefinierte Laufzeit-Supportpaket.

Zu diesem Zeitpunkt befinden wir uns zufällig an einem Punkt, an dem die neueste Version _ebenfalls_ eine LTS-Version ist, was die Notwendigkeit scheint, sie "so schnell wie möglich" von Amazon zu haben, viel "dringender" zu sein, als sie es war. sagen wir, mit eingebauter 2.2- oder 3.0-Unterstützung.

Letztendlich muss ein Kompromiss zwischen neuen Funktionen, die auf Lambda verwendet werden können, und dem Entwicklungsaufwand für PaaS-Lösungen eingegangen werden.

.NET Core 3.1 war nach seiner Veröffentlichung 2-3 Wochen lang nicht einmal im Microsoft Azure App Service verfügbar.

Wenn Sie im Allgemeinen so schnell wie möglich am „Bleeding Edge“ sein möchten, können Sie mit einer kleinen Investition in die kurzfristige Verwendung der benutzerdefinierten Laufzeitunterstützung potenziell jede zukünftige Version von .NET Core in Lambda nach Ihren eigenen Zeitskalen ausführen. Natürlich geht es hier unter anderem um größere Pakete, etwas mehr Code und die Notwendigkeit, eigene Patches durchzuführen.

Bei allem gibt es ein Gleichgewicht und einen Kompromiss, und bei der integrierten Unterstützung wird es realistischerweise immer eine Verzögerung bei der Verfügbarkeit geben, da Software Zeit braucht.

Da große .NET-Releases in Zukunft im November erscheinen, wird die Weihnachts-/Feiertage wahrscheinlich immer einen Einfluss darauf haben, wie lange die Bereitstellung dieser Dinge in Bezug auf die Zeit und die verfügbaren Kapazitäten des Lambda-Teams dauern wird.

Füge nur meine Gedanken hinzu. Ich verstehe, wie wichtig diese Veröffentlichung ist, und ich weiß es zu schätzen, dass Sie es uns mitteilen. Ich nutze dieses Feedback, um die Dringlichkeit auf unserer Seite voranzutreiben. Wie @martincostello erwähnte, war der Zeitpunkt der

Ich war der Typ, der in der Vergangenheit für 2.1 erwähnte, dass ich hoffte, dass die Automatisierung, die wir eingeführt haben, die zukünftige Version beschleunigen würde. Die Automatisierung, die @assyadh eingebaut hat , hat uns wirklich geholfen, aber leider haben sich die Dinge im Laufe der Software seit der

Bitte glauben Sie mir, dass .NET Core 3.1 @assyadh , für mich und viele andere höchste Priorität hat.

Nur um zu überprüfen: Beginnt die Arbeit, es zu integrieren, sobald Microsoft Vorabversionen veröffentlicht, anstatt auf die endgültige Version zu warten? Dies würde vermutlich die Auswirkungen von Weihnachten reduzieren und eine frühere Auslieferung ermöglichen, sobald die endgültige Version herauskommt, da sie nur getestet werden müsste.

Ich nutze dieses Feedback, um die Dringlichkeit auf unsere Seite zu drücken

Danke dafür @normj. Hier sind meine 0,02 $, in der Hoffnung, dass sie auch Ihrer Evangelisation helfen.

Wie @martincostello erwähnte, war der Zeitpunkt der

Wie @mungojam andeutete , war .NET Core 3.1 ab dem 15. Oktober, über einen Monat vor der Veröffentlichung, in der Vorschauversion verfügbar. Außerdem ist es im Grunde eine Bugfix-Version von 3.0 - ich kenne Ihre Tools nicht, aber ich könnte mir vorstellen, dass die Erkundungsarbeiten mit 3.0 beginnen könnten, das am 23. September veröffentlicht wurde und das ganze Jahr in der Vorschau ist. Es ist erwähnenswert, dass 3.1 in der 3.0-Release-Ankündigung ein geschätztes Veröffentlichungsdatum angegeben hat.

.NET Core 3.1 war nach seiner Veröffentlichung 2-3 Wochen lang nicht einmal im Microsoft Azure App Service verfügbar.

.NET Core 3.1 war am 17. Oktober in Azure Functions verfügbar, zwei Tage nach der Veröffentlichung von Vorschau 1.

Sie können sofort sagen, was Sie wollen, wenn jedes Unternehmen 3.1 benötigt, sei es "Bleeding Edge", benutzerdefinierte Laufzeitoptionen usw Kunden. Wenn AWS – nicht Norms Team, sondern AWS insgesamt – dies zu einer Priorität gemacht hätte, hätten sie meiner Meinung nach die Nase vorn und sicherstellen können, dass sie mit Azure konkurrieren.

Ich persönlich schätze es sehr, Optionen unter Cloud-Angeboten zu haben, die ich basierend auf Verdiensten und nicht auf Unternehmensdogmen wählen kann, und ich würde es begrüßen, wenn AWS den nächsten Schritt zur Verbesserung des .NET-Supports unternehmen würde.

Danke @normj , @assyadh und allen anderen, die daran arbeiten, für Ihre Bemühungen.

Es ist möglich, dass das .NET-Team von AWS mit der Veröffentlichung der 3.0-Vorschau sehr gut mit der Vorbereitung auf .NET 3.1 LTS begonnen hat. Die Sache ist die, AWS neigt dazu, hinter den Kulissen wortkarg zu sein, woran sie arbeiten. Dieser Mangel an Transparenz erzeugt Vermutungen. Ich denke, es würde nicht schaden, eine Art Roadmap zu haben, auch wenn sie vorläufig ist und die Daten sich ändern können usw.

Ich denke, das Problem ist, dass das AWS-Team keine Art von ETA veröffentlichen möchte und daher Entwickler im Dunkeln tappen. @normj sagt, das liegt daran, dass er nicht möchte, dass jemand oder ein Unternehmen Zukunftspläne auf der Grundlage dieser ETAs macht. Ist nicht das allgemeine Verständnis, dass eine ETA nur eine Schätzung ist und kein Unternehmen ernsthafte Pläne basierend auf den Schätzungen eines anderen Unternehmens machen sollte, und selbst wenn dies der Fall wäre, kann das Unternehmen AWS nicht dafür verantwortlich machen oder sich darüber ärgern, dass es eine ETA verpasst hat?

Eine ETA ist auch kein bestimmter Tag. Es kann ein Monat sein. Ein Viertel. Und wir sollten mit jeder ETA einverstanden sein und OK, wenn sie verpasst wurde.

Anschauen
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html
es scheint, dass AWS die Laufzeit kurz nach dem Ende der Lebensdauer dieser Laufzeitversion veraltet.

Da .NET Core LTS-Versionen seit 3 ​​Jahren unterstützt werden, sind wir es bereits
"Wir verbringen die Zeit, die wir .NET Core 3.1 Lambdas verwenden können".
Daher verstehe ich, dass die Leute stationär sind, um .NET Core 3.1 auf Lambdas zu erhalten.
Übrigens, ich würde auch eine grundsolide Veröffentlichung bevorzugen, dann etwas überstürztes.

Ich gehe davon aus, dass es in den nächsten ein oder zwei Monaten verfügbar sein wird, aber ein gewisses Engagement von AWS,
auch wenn sehr konservativ für Teams von Vorteil sein könnte, um ihre Operationen zu planen.

Eine andere Sache ist die in dieser Zeit von OSS: Kann die .NET-Community helfen? Wir reden schließlich über github.
Handelt es sich bei dieser "eingebauten" Laufzeit um einen geschlossenen Code?

Außerdem wäre es eine KILLER-Funktion, wenn der Bereitstellungsprozess einen Schalter für ReadyToRun und andere AOT-Kompilierungsfunktionen hätte, sodass die Kaltstartzeiten erheblich verkürzt werden.
Das würde .NET Core SEHR attraktiv auf AWS Lambda, IMO, machen.

@normj und Team:
vielen Dank, dass Sie .NET Core auf AWS großartig gemacht haben

Füge nur meine Gedanken hinzu. Ich verstehe, wie wichtig diese Veröffentlichung ist, und ich weiß es zu schätzen, dass Sie es uns mitteilen. Ich nutze dieses Feedback, um die Dringlichkeit auf unserer Seite voranzutreiben.

Bitte nutzen Sie diesen Beitrag, um die Dringlichkeit auf Ihre Seite zu drücken. In diesem Sinne sind hier meine zwei Pfennige.

Nur um zu überprüfen: Beginnt die Arbeit, es zu integrieren, sobald Microsoft Vorabversionen veröffentlicht, anstatt auf die endgültige Version zu warten?

Frage: Bekommen wir auf diese Frage eine ehrliche Antwort?

Es fühlt sich an, als ob die Antwort selbstverständlich ist. Es fühlt sich an, als ob die Priorität für .NET "Hobby-Ebene" und nicht "Unternehmens-Ebene" ist, wie es sein sollte.

Irgendwo habe ich gehört, dass 1) das gesamte Net Core-Zeug Open Source gemacht wurde und 2) es einige Early-Adopter-Programme gibt, die es Ihnen ermöglichen, bei der tatsächlichen Veröffentlichung "durchzustarten". (Siehe Google für Details.)

Ich bin hier lustig, aber die Wahrheit ist, dass jeder, der .NET verfolgt, dies weiß, also trägt es zur Selbstverständlichkeit bei, in der ich spreche.

Ehrlich gesagt, nach den 2.1-Verzögerungen in der Veröffentlichung hatte ich gehofft, dass die damals vorgenommenen Änderungen bedeuteten, dass wir diesmal (3.1) Unterstützung für das neue Framework nicht mehr als zwei Wochen nach der tatsächlichen Veröffentlichung haben. Ich meine, innerhalb von Stunden nach der Veröffentlichung wäre ideal, aber innerhalb von zwei Wochen fühlt es sich richtig an, etwas Raum für den letzten Schliff / Politur zu geben.

Aber hier sind wir fast zwei Monate draußen und es fühlt sich einfach "hobby-level-ish" an.

@rati-dzidziguri Ich verstehe und schätze Sie, dass Sie eine ETA wünschen, damit Sie entsprechend planen können. In Wirklichkeit geben wir aus diesem Grund im Allgemeinen keine ETA, weil wir uns wirklich bemühen, keine Versprechungen zu machen, von denen wir nicht 100% sicher sind, dass wir sie halten können.

Das ist Denken auf Hobby-Ebene, wie @abukres so elegant

Ich denke, das Problem ist, dass das AWS-Team keine Art von ETA veröffentlichen möchte und daher Entwickler im Dunkeln tappen. @normj sagt, das liegt daran, dass er nicht möchte, dass jemand oder ein Unternehmen Zukunftspläne auf der Grundlage dieser ETAs macht. Ist nicht das allgemeine Verständnis, dass eine ETA nur eine Schätzung ist und kein Unternehmen ernsthafte Pläne basierend auf den Schätzungen eines anderen Unternehmens machen sollte, und selbst wenn dies der Fall wäre, kann das Unternehmen AWS nicht dafür verantwortlich machen oder sich darüber ärgern, dass es eine ETA verpasst hat?

Eine ETA ist auch kein bestimmter Tag. Es kann ein Monat sein. Ein Viertel. Und wir sollten mit jeder ETA einverstanden sein und OK, wenn sie verpasst wurde.

Ich denke, die Tatsache, dass AWS den JEDI-Vertrag an Azure verloren hat, sollte ausreichen, um intern einige Priorisierungsmeetings einzuleiten, da es auf den ersten Blick beweist, dass .NET ein Unternehmen auf Unternehmensebene ist und als solches behandelt werden sollte. Anstatt Ressourcen zu verschwenden, indem Sie versuchen, die Entscheidung zu "klagen", verwenden Sie diese Ressourcen intern, um der .NET-Community etwas Liebe zu schenken. Nutzen Sie dies als einen Moment, um .NET neu zu priorisieren, damit AWS beim nächsten .NET-Release obendrauf ist und sich selbstverständlich macht, dass sie bereit sind, sofort loszulegen.

@normj , @martincostello und der Rest der Arbeiterbienen dort drüben bei AWS arbeiten wirklich hart daran, ein SOLIDE .NET-Angebot bereitzustellen die das Prioritätsmandat diktieren, das Sie in Bezug auf .NET erhalten haben. Bitte verwenden Sie diesen Beitrag, um Support auf Unternehmensebene zu erreichen.

Ich sehe dies hauptsächlich als verpasste Gelegenheit für AWS, zu glänzen. Stellen Sie sich vor, die Verfolgung einer neuen LTS-Version hätte eine hohe Priorität. Was wäre das für eine starke Aussage.

Solche Dinge führen dazu, dass wir Entwickler/Architekten Argumente gegen nicht-technische Entscheidungsträger verlieren, wenn wir entscheiden müssen, welche Cloud wir für das nächste Projekt verwenden möchten. Heutzutage, in denen sowohl Azure als auch AWS größtenteils gleiche Kosten- und Funktionsangebote haben, werden Entscheidungen mehr nach Politik und Wahrnehmung getroffen. Ich habe nichts mitzubringen, wenn sie sagen "es sind X Wochen/Monate nach der offiziellen Veröffentlichung vergangen und AWS ist immer noch nicht bereit"

Wie @VagyokC4 sagt, ist dies wiederum nicht persönlich gegen die Mitarbeiter, die die eigentliche Arbeit

Jeder, der .NET Core 3.1 Lambda verwendet, könnte in Betracht ziehen, das IL-Trimming zu aktivieren. Höchstwahrscheinlich werden Sie die Größe Ihrer ZIP-Dateien reduzieren.
https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx

wird .NET Core Lambda 3.1 mit RuntimeAPI erstellt?
im freien, auf github?
wenn nein, warum nicht?

Alles, was ich für ... Valentinstag will, ist Lambda .net Core 3.1-Unterstützung

Alles, was ich für ... Valentinstag will, ist Lambda .net Core 3.1-Unterstützung

Rollt nicht gerade von der Zunge, ist aber bescheiden:

Ich will nicht viel zu Weihnachten Valentinstag
Ich brauche nur eins
Die Geschenke sind mir egal
Unter dem AWS-Baum
Ich will es nur für mich
Mehr als du jemals wissen könntest
Lass meinen Wunsch wahr werden oh
Alles, was ich zum Valentinstag will, ist .NET Core 3.1 suppoooooort ...

:Grinsen:

Microsoft fügt Go-Live-Lizenzen gegen Ende ihres Vorschauzyklus hinzu, wenn keine wichtigen Änderungen eingeführt werden. Zu diesem Zeitpunkt bieten sie Produktionsunterstützung für diese bevorstehende Veröffentlichung an. Meine Empfehlung wäre, zu warten, bis eine Version mit einer Go Live-Lizenz veröffentlicht wird, und dann mit der Arbeit an den Tools zu beginnen. Mit .NET Core 3.1 kam es in Preview 3, die am 14.11. veröffentlicht wurde. In diesem Fall war das RTM noch nicht einmal 3 Wochen später am 3. 12., aber Sie wären immer noch näher daran, die Funktionen einzuführen, wenn RTM eintrifft und die Kunden anfangen, Erwartungen zu wecken.

Nur meine 0,02 $

Alles, was ich für ... Valentinstag will, ist Lambda .net Core 3.1-Unterstützung

Rollt nicht gerade von der Zunge, ist aber bescheiden:

Ich will nicht viel für ~Weihnachten~ Valentinstag
Ich brauche nur eins
Die Geschenke sind mir egal
Unter dem AWS-Baum
Ich will es nur für mich
Mehr als du jemals wissen könntest
Lass meinen Wunsch wahr werden oh
Alles, was ich zum Valentinstag will, ist .NET Core 3.1 suppoooooort ...

😁

+1 :)

Gibt es ein Update zur .NET Core 3.1-Laufzeit für Lambda?

Wir starten ein neues Projekt und wollten Lamba für die meisten Serverless-Dienste verwenden, aber zu sehen, wie lange es dauert, bis eine LTS-Version unterstützt wird, lässt uns umdenken und möglicherweise die Architektur oder den Anbieter wechseln.

<Rant>
Es ist frustrierend, dass die AWS Lambda Runtime-Supportrichtlinie in Bezug auf das 30-Tage-Fenster sehr streng ist, wenn Funktionen wie diese länger als 30 Tage angefordert werden. Dann wird AWS eines Tages diese Funktion auf magische Weise bereitstellen und alle anderen müssen sich um den Umstieg auf .NET Core 3.1 bemühen. Dies bringt die meisten Unternehmen in eine schlechte Position, da es oft länger als einen Monat dauert, etwas zu reparieren, zu testen und in einer Produktionsumgebung bereitzustellen. Ich persönlich bin von dieser Politik in den Hintern gebissen worden. Einmal (wegen Ressourcenzwängen und anderen höheren Prioritäten) eine Firma, bei der ich diesmal rutschen durfte. Erst 3 Monate später konnten wir unsere Lambdas auf .NET Core 2.1 aktualisieren. Als wir versuchten, ein bestimmtes Lambda mit CloudFront bereitzustellen, passierte etwas Schlimmes (was? wer weiß, weil CF-Protokolle Müll sind) und es musste ein Rollback durchgeführt werden. Außer, dass es keine Laufzeit zum Zurücksetzen gab. Somit ist es LOCKED die Bereitstellung. Wir haben sofort ein Ticket geöffnet. 24 Stunden später erhielten wir unsere erste Antwort, die lautete: "Löschen Sie den gesamten Stapel und beginnen Sie von vorne". Was eine völlig ignorante Antwort ist, wenn man bedenkt, dass unsere DynamoDb-Tabellen mit der Operation "Löschen" benötigt würden. Wir waren über zweieinhalb Wochen in diesem Rollback eingesperrt. Schließlich bekamen wir einen Support-Ingenieur, der Container-Technologien verstand und uns beim Rollback half und dann in der Leitung blieb, bis unsere CloudFormation erfolgreich war. Was es gut gemacht hat, keine Änderung zum ersten Versuch. Aus diesem Grund hasse ich CF jetzt, da sie zu temperamentvoll ist.
</Rant>

TL;DR; Es ist unangenehm, mit der AWS Lambda Runtime Support-Richtlinie zu arbeiten und kann Sie in heißes Wasser stürzen.
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html

@CraigHead Entschuldigung für Ihre frustrierende Erfahrung, aber um das

Ja, es war die Migration von .NET Core 2.0 vorwärts zu .NET Core 2.1. Entschuldigung für das Gerede. 30 Tage sind für einige von uns ziemlich knapp. Betrachtet man die Gesamtlänge, könnte ein Lambda potenziell ohne nennenswerte Wartung und zusätzliche Qualitätssicherung laufen.

Inzwischen geschieht dies auf der Azure-Seite von Serverless
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

Inzwischen arbeitet das AWS-Team daran. Snarky Kommentare helfen nicht
Sie. Sie werden dieses Problem aktualisieren, wenn es fertig ist.

Am Di, 11. Feb. 2020 um 18:22 Uhr, Rati Dzidziguri [email protected]
schrieb:

Inzwischen geschieht dies auf der Azure-Seite von Serverless

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

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAAZVJXAAYET4F7PFFOTO3LRCLUETA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63DNPWMZ5
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAAZVJQK3NBVXBZALM4V5KLRCLUETANCNFSM4JU5UTJA
.

Es ging mir nicht darum, einen bissigen Kommentar abzugeben, sondern darauf hinzuweisen, dass sogar MS vor kurzem die Verfügbarkeit von GA für 3.1 angekündigt hat.
.

Inzwischen geschieht dies auf der Azure-Seite von Serverless
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

Wenn man bedenkt, dass es sich um eine MS-Sprache handelt, überrascht es nicht, dass Azure AWS bei dieser Unterstützung besiegt hat.

Ich beobachte diesen Thread genau - ich freue mich darauf, meine C#-Lambdas zu aktualisieren.

dotnet core 3.1.0 wurde veröffentlicht 2019-12-03
https://dotnet.microsoft.com/download/dotnet-core/3.1

es war am 23.01.2020 in Azure verfügbar
https://azure.microsoft.com/en-us/updates/azure-functions-runtime-30-is-now-available/

wir haben etwas weniger als einen zusätzlichen Monat im Vergleich zu Azure

Übrigens, die gesamte .NET-Kernentwicklung erfolgt im Freien auf github
Daher sollte es keine große Wirkung haben, "MS-Sprache" zu sein.
Oder schlagen Sie vor, dass AWS-Clients, die dotnet verwenden, in Azure besser geeignet sind: P?

Wie auch immer, an alle, die AWS hören:
da warten wir auf 3.1 auf Lambda, das ist uns wichtig.

Übrigens, die gesamte .NET-Kernentwicklung erfolgt im Freien auf github
Daher sollte es keine große Wirkung haben, "MS-Sprache" zu sein.
Oder schlagen Sie vor, dass AWS-Clients, die dotnet verwenden, in Azure besser geeignet sind: P?

Ich meine, es wäre ein bisschen peinlich für die Cloud-Plattform von Microsoft, die neuen Funktionen ihrer eigenen Sprache nicht zu unterstützen. Um ehrlich zu sein, bin ich ein wenig überrascht, dass sie etwas mehr als anderthalb Monate gebraucht haben! Etwas mehr interne Kommunikation hätte vielleicht beides gleichzeitig freigegeben.

Ich denke, AWS schneidet mit seiner .Net-Unterstützung gut ab, insbesondere mit Entwicklungspaketen, die sich in ihre Dienste einklinken, wie CloudWatch + ILogging und ihre SSM-Parameterkonfiguration. Es hat uns sehr geholfen.

Ich hoffe jedoch, die 3.1-Version bald zu sehen :)

Ich wünschte, es gäbe eine bessere konkrete Cloudwatch-Implementierung von ILogger . Dies wäre besser in ServiceCollection / ServiceProvider wenn das Lambda SDK verwendet wird. Die aktuelle Version, die im Anfragekontext und der statischen LambdaLogger-Klasse bereitgestellt wird, ist grundsätzlich unmöglich, die Protokollausgabe zu testen / zu überprüfen, und das Einhängen der standardmäßigen .netcore ConsoleLogProvider führt zu unordentlichen Cloudwatch-Protokollen.

Ich wünschte, es gäbe eine bessere konkrete Cloudwatch-Implementierung von ILogger .

Haben Sie https://github.com/aws/aws-logging-dotnet#aspnet -core-logging ausprobiert?

Wie sollen Ihre Logs aussehen @CraigHead?

Wir haben in der Vergangenheit Serilog & https://github.com/structured-log/structured-log verwendet, um schöne Konsolenprotokolle und auch JSON-basierte Protokolle auszugeben, die in Seq importiert wurden. https://datalust.co/ das war für uns der beste Weg, um zentrale Protokolle in einem wirklich schönen Format zu erhalten.

@CraigHead Amazon.Lambda.Logging.AspNetCore ist unsere Implementierung zur Integration der Lambda-Anmeldung in die IServiceCollection. Funktioniert diese Bibliothek nicht für Sie?

Ich würde das AWS.Logger.AspNetCore-Paket von ttps://github.com/aws/aws-logging-dotnet#aspnet -core-logging für Lambda nicht empfehlen. Diese Bibliothek verwendet einen Hintergrundthread, um Protokolle an CloudWatch Logs zu übertragen. Die Verwendung eines solchen Hintergrundthreads funktioniert nicht gut mit Lambda, das die Lambda-Rechenumgebung einfriert, sobald der Funktionshandler zurückkehrt, was bedeutet, dass der Hintergrundthread möglicherweise keine Chance hat, die Nachrichten in der Warteschlange zu leeren.

Ich wusste davon nicht. Danke für den Tipp!
Ich bezog mich auf das Amazon.Lambda.Core.LambdaLogger im SDK.
Ich werde das Paket ( Amazon.Lambda.Logging.AspNetCore ) auf jeden Fall überprüfen.

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

@clearwaterstream
In Lambda-Land AFAIK gibt es kein Ereignis, das Sie darüber informiert, dass die aktuelle Instanz die Verarbeitung stoppt oder beendet wird, sodass Ihr Vorschlag gepufferte Protokollereignisse weiterhin nicht gelöscht (verloren) lässt.

Bitte entführt diesen Thread nicht für andere Zwecke.
Dieser Thread wurde erstellt, um einige Informationen zu geben, wann .NET Core 3.1 auf AWS Lambda verfügbar sein wird.
Und um AWS wissen zu lassen, dass wir da draußen sind und warten.

Wird das Lambda-Testtool in der Version 3.1 enthalten sein? https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

Das ist meine Absicht. Die Arbeit läuft im mock-testtool-31 . Die große Verbesserung im 3.1-Zweig besteht darin, dass der Benutzer-Lambda-Code jetzt in einem separaten AssemblyLoadContext ausgeführt wird, was viele Versionskonflikte beheben sollte, die Benutzer mit der aktuellen Version hatten. Ich schaue mir die Rückportierung der AssemblyLoadContext-Funktion in die Version 2.1 an.

Als Randnotiz. Ich habe darüber diskutiert, die Bare-Bones-Benutzeroberfläche in eine serverseitige Blazor-App umzuwandeln. Hat jemand mit mehr Blazor-Erfahrung Feedback, ob das eine gute oder schlechte Idee ist?

Als Randnotiz. Ich habe darüber diskutiert, die Bare-Bones-Benutzeroberfläche in eine serverseitige Blazor-App umzuwandeln. Hat jemand mit mehr Blazor-Erfahrung Feedback, ob das eine gute oder schlechte Idee ist?

Alles, was Blazor an dieser Stelle ist, ist eine gute Idee, besonders für diejenigen von uns, die DotNet rocken!

"Bare Bones UI" - Dies ist eine andere App, die nicht mit .NET Core 3.1 Lambdas verbunden ist?
Übrigens, ich interessiere mich überhaupt nicht für blazor

@petarrepac Dies bezog sich auf das AWS .NET Mock Lambda Test Tool, das wir ausgeliefert haben, um das Debuggen von .NET Core 2.1 Lambda-Funktionen zu unterstützen. Hier ist der Beitrag als Referenz https://aws.amazon.com/blogs/developer/debugging-net-core-aws-lambda-functions-using-the-aws-net-mock-lambda-test-tool/

Ich bin dabei, das Tool für .NET Core 3.1 zu aktualisieren.

@normj
ah, hab das nicht verstanden, danke
Interessanter Gedanke, dass wir so ein Tool nie gebraucht haben

Aus unserer Sicht ist Lambda eine Barebone-AspNetCore HttpApi, die Sie lokal aufrufen und lokal testen können
Der einzige Unterschied besteht in der Einstiegspunktdatei/-klasse, die weniger als 50 Codezeilen enthält
Außerdem können viele Dinge nur richtig getestet werden, wenn sie in AWS bereitgestellt werden:

• Berechtigungen
• Form der empfangenen JSON-Ereignisse und Kontext
• ...
  also eine kombination aus:
• gute Einheiten-/Integrationstests, die lokal ausgeführt werden
• lokale http-Tests
• Einfache Bereitstellung zum Testen der AWS-Umgebung
  kann weit gehen

oder übersehe ich irgendein offensichtliches Szenario?

@petarrepac Einer der großen Vorteile der Verwendung der ASP.NET Core-Bridge besteht darin, dass sie sehr einfach lokal ausgeführt werden kann. Ich stimme zu, dass die beste Vorgehensweise darin besteht, Unit/Integration-Tests zu verwenden, aber es gibt oft Bedarf für schnelle Ad-hoc-Tests der Anwendungslogik, und dafür ist dieses Tool gut.

Danke @normj. In Bezug auf Blazor könnte es eine nette Geste sein. Zumindest für den Anwendungsfall unseres Teams würde es wahrscheinlich nicht ausgelastet sein.

Wir sind nur lange genug in der Benutzeroberfläche, um eine Nutzlast zu senden, und gehen dann den Code in VS durch.

Mit dem Lambda Bootstrapper und der benutzerdefinierten Laufzeitfunktion können Sie definitiv mehrere Lambda-Funktionen aus einer Codebasis erreichen.

Ich habe eine Suite von 16 Lambdas, die von einer Anwendung und nicht von einem „Monolithen“ bereitgestellt werden.

Dies wird erreicht, indem die Umgebungsvariable _handler wird, um die Methode auszuwählen, die zur Laufzeit verwendet werden soll, und nicht die hartcodierte Eins-zu-Eins-Zuordnung, die im Beispielcode des Blogposts gezeigt wird.

Ich stelle es mir als Konsolen-App vor, die einen Schalter erhält, der ihr mitteilt, welche Aktion beim Start ausgeführt werden soll.

@martinkostello

Ich habe einige Probleme, dies aufgrund Ihrer Erklärung zu lösen. Ich habe etwa 20 Lambda-Funktionen in meiner Functions.cs, die an entsprechende Definitionen in meiner serverless.template gebunden sind. Ich verstehe, dass Sie mit jeder Definition eine Umgebungsvariable übergeben würden, um anzugeben, welche Funktion aufgerufen werden soll. Die meisten dieser Funktionen sind von der Signatur:

public APIGatewayProxyResponse ThisLambdaFunction(APIGatewayProxyRequest-Anfrage, ILambdaContext-Kontext)
{

Wie füge ich Unterstützung für verschiedene Lambda-Funktionssignaturen hinzu, wenn ich andere Funktionen habe, die andere Argumente (außer APIGatewayProxyRequest ) und andere Rückgabetypen verwenden?

Bitte den Thread nicht entgleisen.

@twopointzero Ich habe Tage damit verbracht, bei Google nach einer Lösung für das Ausführen mehrerer Lambda-Funktionen mit dem .NET Core 3.1 Custom Runtime-Projekt zu suchen. Es gibt keinen relevanteren Thread im Internet und ich antworte auf einen bestehenden Beitrag, der einen Hoffnungsschimmer auf eine Lösung meines Problems gegeben hat.

Die fehlende native .NET Core 3.1-Unterstützung in AWS macht das Leben schwer. Wir müssen auf 3.1 aktualisieren, um auf den neuesten EntityFramewore Core 3.1.2 zu aktualisieren, der Probleme behebt, die wir beim Verbindungspooling in Aurora (PostgresSQL) sehen.

@normj Ich verstehe die Haltung ohne ETA völlig, aber können Sie mir sagen, ob wir nahe dran sind? < 30 Tage?

@antsaia In Bezug auf die Bereitstellung eines verteilten Monolithen mit benutzerdefinierter Laufzeitunterstützung, nicht in Bezug auf AWS Lambda-Unterstützung für .NET Core 3.1. Wenn Sie im Internet keinen relevanteren Thread finden, möchte ich Sie bitten, einen zu erstellen, anstatt einen zu entgleisen.

Um diesen Thread nicht selbst zu entgleisen, ist dies mein letzter Kommentar zu diesem Thema.

@normj Gibt es eine Ressource (Blog, Forum usw.), in der wir Informationen über den Status der Implementierung des .net Core 3.1-Supports erhalten?

Ich besuche diese Seite täglich in der Hoffnung, neue Informationen zu erhalten, aber offensichtlich gibt es nicht genug Informationen (da sie nicht für diesen Zweck bestimmt sind). Es würde es viel einfacher machen, wenn wir eine Art grundlegendes Update hätten, damit wir vorausplanen können.

Wie viele hier hängen unsere Pläne für die Bereitstellung von Funktionen stark davon ab, ob wir 3.1 verwenden können oder ob wir es mit 2.1 entwickeln müssen. In meinem Fall wird 3.1 System.Draw unterstützen und dies hat einen großen Einfluss auf das Feature, an dem ich arbeiten soll.

Alles, was ich für ... St. Patrick's Day will, ist Lambda .net Core 3.1-Unterstützung

@liam-sage Alles, was ich finden konnte, waren ein paar Beiträge im Amazon-Forum, die darauf hindeuteten, dass es im ersten Quartal 2020 fertig sein würde. https://forums.aws.amazon.com/thread.jspa?threadID=313806

@liam-sage Alles, was ich finden konnte, waren ein paar Beiträge im Amazon-Forum, die darauf hindeuteten, dass es im ersten Quartal 2020 fertig sein würde. https://forums.aws.amazon.com/thread.jspa?threadID=313806

Das bedeutet, dass es im März live gehen muss. Ich warte.

Hallo, ich weiß, es ist nicht ganz geeignet, aber Sie können Ihre eigenen Lambdas auf dotnetcore 3.1 aktualisieren. In der Zwischenzeit, während Sie warten, würde ich vorschlagen, dass Sie viele Lambdas erstellen, um Ihre eigene Dotnetcore-Vorlage zu schreiben. Das habe ich für mich gemacht. Ich wollte sicherstellen, dass ich keine Stunden mit Boilerplate-Code verschwenden muss. Ein Beispiel für eine Vorlage finden Sie hier .

Und Vincent, wie hosten wir es dort? Benutzerdefinierte Laufzeit verwenden?
Am Do, Mär 5, 2020 um 19:40 Vincent van der Walt <
[email protected]> schrieb:

Hi, ich weiß, es ist nicht ganz geeignet, aber du kannst deine eigenen Lambdas bekommen
auf dotnetcore 3.1 aktualisiert. In der Zwischenzeit, während Sie warten, würde ich vorschlagen
wenn Sie viele Lambdas erstellen, um Ihre eigene Dotnetcore-Vorlage zu schreiben. Ich tat
das für meine. Ich wollte sicherstellen, dass ich keine Stunden damit verschwenden muss
Boilerplate-Code. Ein Beispiel für eine Vorlage finden Sie hier
https://github.com/vincentvanderwalt/aws-lambda-dotnetcore-3-template .

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AGIDH4OWUT7Y3HR3O5KARBDRF62V3A5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVXZH63Lcom26
oder abmelden
https://github.com/notifications/unsubscribe-auth/AGIDH4PLKFSDLNBX2QVMG63RF62V3ANCNFSM4JU5UTJA
.

Ja, es nutzt die benutzerdefinierte Laufzeit.

Sie können es lokal auf Ihrem Computer ausführen oder in AWS bereitstellen.

F5 für lokal und dotnet lambda deploy-serverless für die Bereitstellung in AWS

Die Readme-Datei erklärt, wie Sie die Vorlage auf Ihrem lokalen Computer installieren (es ist eine Dotnetcore-Vorlage).

Benutzerdefinierte Laufzeiten sind cool, aber ich warte immer noch auf die vollständige AWS-Unterstützung für .Net Core 3.1 für Lambdas, um sie in Produktionsumgebungen zu verwenden 😄

Jedes Mal, wenn ich das in meinem Posteingang sehe, öffne ich es eifrig, um zu sehen, ob @normj es hat
alles angekündigt, nur um ein Posting zu finden, das zumindest ein bisschen abweicht
Thema. Jemand anderes hat andere gebeten, den Thread nicht zu kapern, und das ist nicht der Fall
hat funktioniert. Kann jemand den Thread sperren, bis jemand bereit ist, das anzukündigen?
Release von 3.1-Unterstützung?

Am Fr, 6. Mär 2020 um 07:13 bartoszsiekanski [email protected]
schrieb:

Benutzerdefinierte Laufzeiten sind cool, aber ich warte immer noch auf den vollständigen AWS-Support
für .Net Core 3.1 für Lambdas, um sie in Produktionsumgebungen zu verwenden 😄

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAVUT3SNDR4L2ZL5J4KQYDDRGDSHBA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVXZH63Lcom2009
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAVUT3TBH3NIBMGB54EFCR3RGDSHBANCNFSM4JU5UTJA
.

Bitte erstellen Sie separate Issues für alles andere als die Erörterung der .NET Core 3.1-Unterstützung. Kann ich dieses Thema schließen, bis wir mehr Neuigkeiten @normj haben ?

@ hounddog22030 Ich wusste nicht, dass ich den Thread "entführt" habe. Ich habe vorgeschlagen, dass es, anstatt ständig zu fragen, ob es fertig ist, alternative Ansätze gibt, wenn die Leute unbedingt auf dotnetcore 3.1 umsteigen wollen. Offizieller nicht benutzerdefinierter Runtime-Support wird verfügbar sein, wenn er fertig ist. Die Leute müssen nur ein wenig geduldiger sein oder einen alternativen Ansatz suchen.

Wenn AWS die Option --self-contained im Befehl dotnet lambda package unterstützt, müssen die Lambda-Funktionen unabhängig von ihrer SDK-Version ausführbar sein. rechts? Warum nicht, anstatt Unterstützung für jede .NET Core-Version hinzuzufügen?

Wenn AWS die Option --self-contained im Befehl dotnet lambda package unterstützt, müssen die Lambda-Funktionen unabhängig von ihrer SDK-Version ausführbar sein. rechts? Warum nicht, anstatt Unterstützung für jede .NET Core-Version hinzuzufügen?

Sie haben gerade die benutzerdefinierte Lambda-Laufzeitfunktion beschrieben

@aussiearef Das funktioniert in der Tat gut, aber das in sich geschlossene Paket enthält .Net Core selbst, was normalerweise mindestens 40 MB (gezippt) für eine Website ausmacht – und nicht viel Platz für die Anwendung und Abhängigkeiten selbst lässt.

Bei Verwendung derselben Version von .NET Core ist die benutzerdefinierte Laufzeit auch langsamer (Kaltstarts) als die native Laufzeit. 3.1 fügt viele Leistungsverbesserungen hinzu, sodass Sie zwischen 3.1 benutzerdefiniert vollständig optimiert und 2.1 nativ das gleiche Leistungsniveau erwarten können. Ich hoffe, dass 3.1 native wesentliche Verbesserungen bringen wird.

Q1 wird in 4 Tagen enden, aber es sieht so aus, als würden wir 3.1 in Lambda nicht sehen.
Ich hoffe, dass alle Mitglieder des Teams in dieser Zeit der Pandemie sicher sind und hoffe, diese Veröffentlichung im zweiten Quartal zu sehen.

Gib die Hoffnung nicht auf, wir haben noch ein paar Tage! Wir sind alle ziemlich fertig damit, auf die endgültigen Bereitstellungen und andere Last-Minute-Aktivitäten zu warten. Denken Sie daran, dass wir alle Software kennen und es in letzter Minute zu Schluckauf kommen kann.

Ich plane eigentlich, bald mit dem Rollout der neuen Client-Tooling-Updates zu beginnen, um sicherzustellen, dass alles verfügbar ist, sobald die Laufzeit geöffnet ist. Wenn Sie also sehen, dass neue NuGet-Paketupdates veröffentlicht werden, gehen Sie nicht davon aus, dass die Laufzeit vorhanden ist. Warten Sie, bis der Blogbeitrag veröffentlicht ist, und ich werde hier ein Update veröffentlichen.

Das sind fantastische Neuigkeiten. Danke @normj

Freue mich auf den Blogbeitrag und die Veröffentlichung.

Gib die Hoffnung nicht auf, wir haben noch ein paar Tage! Wir sind alle ziemlich fertig damit, auf die endgültigen Bereitstellungen und andere Last-Minute-Aktivitäten zu warten. Denken Sie daran, dass wir alle Software kennen und es in letzter Minute zu Schluckauf kommen kann.

Ich plane eigentlich, bald mit dem Rollout der neuen Client-Tooling-Updates zu beginnen, um sicherzustellen, dass alles verfügbar ist, sobald die Laufzeit geöffnet ist. Wenn Sie also sehen, dass neue NuGet-Paketupdates veröffentlicht werden, gehen Sie nicht davon aus, dass die Laufzeit vorhanden ist. Warten Sie, bis der Blogbeitrag veröffentlicht ist, und ich werde hier ein Update veröffentlichen.

Deine Geduld angesichts der Haltung in diesem Thread ist mehr als beeindruckend. Danke, dass Sie daran gearbeitet haben!

@normj hilft

Noch 2 Tage und Daumen drücken.

Und mit noch 13 Stunden im Viertel ist Schluss

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

Danke an alle für eure Geduld. @raRaRa Ich werde Ihnen die Ehre überlassen, diese Ausgabe

Groß

Am Di, 31 Mär 2020, 20:06 schrieb Norm Johanson, [email protected] :

Und mit noch 13 Stunden im Viertel ist Schluss

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

Danke an alle für eure Geduld. @raRaRa https://github.com/raRaRa
Ich überlasse Ihnen die Ehre, diese Ausgabe abzuschließen.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-606785798 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AGUX3OUR6LN5CERIBTDHXP3RKIWLVANCNFSM4JU5UTJA
.

Danke schön!!!!

Und.... Abmelden :-)

Danke an alle Beteiligten!!!

Vielen Dank!

Und mit noch 13 Stunden im Viertel ist Schluss

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

Danke an alle für eure Geduld. @raRaRa Ich werde Ihnen die Ehre überlassen, diese Ausgabe

Gute Arbeit!

Das ist AWS-Baby. Das ist AWS!!!
Egal was passiert, am Ende schaffen sie es.

Vielen Dank, Team!!!

Tolle Neuigkeiten und vielen Dank @raRaRa @normj !!! Auf die Gefahr hin, albern und/oder gierig zu klingen, heißt das eigentlich auch Powershell 7? Einfach nochmal prüfen......

Tolle Arbeit @normj und alle bei AWS! 🥳

Hier ist der Link zum Blog für diejenigen, die nach unten scrollen
https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

großartig, vielen Dank für die Unterstützung von Dotnet Core 3.1!!!

@andyKalman Noch nicht auf PowerShell 7. Ich mache einige letzte Nachbesserungen am AWSLambdaPSCore-Modul und werde dann die Version 2.0.0 von AWSLambdaPSCore in die Galerie bringen.

Ich freue mich über die schnelle Antwort

Herzlichen Glückwunsch!
Und vielen Dank an das AWS- und .NET-Team!
Sehr geschätzt.

Vielen Dank an alle, die mitgeholfen haben, dies zu ermöglichen! Dies ist eine riesige Veröffentlichung und es zeigt, dass viel harte Arbeit darin steckt! Schön! 🎉🥳

Vielen Dank !! : klatschen:: klatschen:: tada:: tada:

Herzlichen Glückwunsch Jungs, ich freue mich auf das Upgrade.

Vielen Dank!

Tolle Arbeit, ich möchte diese Lambdas aktualisieren.

Gute Arbeit! Danke @normj 👏 👏

Tolles Arbeitsteam!

Begierig darauf, auf Lambda-Worker mit dotnet 3.1 Async Streams + AWS AppSync/GraphQL-Abonnements aufzuspringen.
AWS-Team, vielen, vielen Dank!

OMG, Leute, ihr regiert! Tolle! Huhu! 😄😄😄

DANKE!

@andyKalman Ich habe Version 2.0.0 des AWSLambdaPSCore-Moduls veröffentlicht, das jetzt PowerShell 7 verwendet. Ich habe vor, einen Blogbeitrag zur PS7-Unterstützung zu veröffentlichen, aber es verhält sich genauso wie die vorhandene PowerShell 6-Unterstützung verwendet nur 7.

@andyKalman Ich habe Version 2.0.0 des AWSLambdaPSCore-Moduls veröffentlicht, das jetzt PowerShell 7 verwendet. Ich habe vor, einen Blogbeitrag zur PS7-Unterstützung zu veröffentlichen, aber es verhält sich genauso wie die vorhandene PowerShell 6-Unterstützung verwendet nur 7.

Aktualisiert die neue Version von AWSLambdaPSCore eine der Konfigurationen in meinen vorhandenen Lambda-Funktionen, wenn ich sie mit der neuen Version veröffentliche? Wie wird es auf dotnet3.1 und ps7 hinweisen?

@ tr33squid Ja, wenn Sie mit 2.0.0 bereitstellen, werden .NET Core 3.1 und PS7 verwendet

Vielen Dank und tolle Arbeit AWS-Team!!

Hallo allerseits,

Ich arbeite aktiv daran, die Unterstützung für .NET Core 3.1 in Lambda bereitzustellen. Es dauert einige Zeit, da von Microsoft viel Arbeit geleistet wurde, um die Laufzeit zu erstellen. Ich arbeite daran, diese Änderungen zu integrieren, um Ihnen eine native Laufzeitumgebung zu bieten.

Danke an das AWS-Lambda .NET-Kernteam

Hi,
Ich erhalte diesen Fehler, wenn ich versuche, AWS-Lambda auszuführen
Es konnte keine kompatible Framework-Version gefunden werden.
Das angegebene Framework 'Microsoft.AspNetCore.App', Version '3.1.0' wurde nicht gefunden.
irgendwelche Vorschläge ??

Hi,
Ich erhalte diesen Fehler, wenn ich versuche, AWS-Lambda auszuführen
Es konnte keine kompatible Framework-Version gefunden werden.
Das angegebene Framework 'Microsoft.AspNetCore.App', Version '3.1.0' wurde nicht gefunden.
irgendwelche Vorschläge ??

Sie müssen das 3.1.0 SDK installieren.

Ich glaube, Microsoft.AspNetCore.App sollte aus Ihrem Projekt entfernt werden
Abhängigkeiten, für Core 3.1.0 nicht mehr benötigt, musste ich entfernen um
den Dienst erstellen und bereitstellen, den ich von 2.1 aktualisiert habe.

Am Fr, 24. April 2020 um 03:24 Gregory Lyons [email protected]
schrieb:

Hi,
Ich erhalte diesen Fehler, wenn ich versuche, AWS-Lambda auszuführen
Es konnte keine kompatible Framework-Version gefunden werden.
Das angegebene Framework 'Microsoft.AspNetCore.App', Version '3.1.0' war
nicht gefunden.
irgendwelche Vorschläge ??

Sie müssen das 3.1.0 SDK installieren.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-618850277 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA
.

--
Am besten,
George

George Taskos
Senior Solutions Architect

WeAre8
230 Park Avenue, 3. fl. Westen
New York, NY 10169
(917) 717-9067
weare8.com

Privater Eingang,
71 Vanderbilt Avenue
3. Stock

Ich glaube, Microsoft.AspNetCore.App sollte aus Ihren Projektabhängigkeiten entfernt werden und wird für Core 3.1.0 nicht mehr benötigt. Ich musste es entfernen, um den Dienst zu erstellen und bereitzustellen, den ich von 2.1 aktualisiert habe.
…
Am Fr, 24. April 2020, 03:24 Gregory Lyons @ . * > wrote: Hallo, ich erhalte diesen Fehler beim Versuch, AWS-Lambda auszuführen. Es war nicht möglich, eine kompatible Framework-Version zu finden. Das angegebene Framework 'Microsoft.AspNetCore.App', Version '3.1.0' wurde nicht gefunden. irgendwelche Vorschläge ?? Sie müssen das 3.1.0 SDK installieren. — Sie erhalten dies, weil Sie diesen Thread abonniert haben. Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub < #554 (Kommentar) > an oder melden Sie sich ab https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA .
-- Best, George George Taskos Senior Solutions Architect WeAre8 230 Park Avenue, 3th fl. West New York, NY 10169 (917) 717-9067 weare8.com Privater Eingang, 71 Vanderbilt Ave 3rd Floor

Danke für deine Antwort,
Eigentlich war dieser Fehler auf meinen dummen Fehler zurückzuführen. Ich habe vergessen, die Laufzeit: dotnetcore2.1 in meiner serverless.yml zu entfernen. Jetzt Problem gelöst.

Hat jemand aktualisierte Benchmarks/Vergleiche dazu? Alles, was ich finden kann, sind alte mit einer benutzerdefinierten Laufzeit.

Hat jemand aktualisierte Benchmarks/Vergleiche dazu? Alles, was ich finden kann, sind alte mit einer benutzerdefinierten Laufzeit.

Hier ist ein guter.
https://medium.com/@zaccharles/a -close-look-at-net-core-3-1-on-aws-lambda-9ccec4dd96be

Auch meine persönliche Erfahrung mit der Aktualisierung eines 2.1-Komplex-Lambda auf 3.1 auf einer Lambda-Größe von 512 MB ergab fast die gleiche Leistung (Kalt- und Warmstart). Sowohl die 2.1- als auch die 3.1-Lambda verwenden Lambda-Layer, optimierte Veröffentlichung, Newtonsoft (möglicherweise eine Leistungsverbesserung mit Microsoft json in 3.1), abgestufte Kompilierung und RTR für 3.1.

Nach meinen Metriken scheint es mit der dotnet 3.1-Laufzeit leicht an Leistung zu gewinnen, aber die Leistung bei Amazon Linux 2 und der dotnet 3.1-Initialisierung zu verlieren. (2.1 verwendet Amazon Linux 1.) Gewinne eine Wäsche zu machen.