Aws-lambda-dotnet: Se lanzó .NET Core 3.1 (LTS)

Es un LTS y será compatible. Solo tomará algún tiempo tener .NET Core 3.1 listo para Lambda e implementado.

Es un LTS y será compatible. Solo tomará un tiempo tener .NET Core 3.1 listo para Lambda e implementado.

Si hay algo que pueda hacer para ayudar, hágamelo saber.

¿Habrá una aceleración para la hora de inicio en frío?

.NET Core 3.1 tiene algunas características como la compilación AOT

• PublishReadyToRun
• PublishTrimmed

@normj ¿las personas deberían suscribirse a este problema para

Podemos utilizar este problema para realizar un seguimiento de las actualizaciones. Desafortunadamente, probablemente no pueda proporcionar muchas actualizaciones de estado hasta que esté disponible.

¿Habrá una aceleración para la hora de inicio en frío?

.NET Core 3.1 tiene algunas características como la compilación AOT

• PublishReadyToRun
• PublishTrimmed

En caso de que la respuesta sea sí para el comentario, ¿será posible ejecutar y probar la 'lambda compilada' desde un entorno local? Con entusiasmo establecería un entorno Linux para ello :)

¿Alguna actualización aquí?

@ rati-dzidziguri

Como arriba de @normj

Podemos utilizar este problema para realizar un seguimiento de las actualizaciones. Desafortunadamente, probablemente no pueda proporcionar muchas actualizaciones de estado hasta que esté disponible.

@beeradmoore
Mi pregunta fue sobre ETA. Sería útil conocer a ETA para esto, ya que podríamos prepararnos en consecuencia.

@ rati-dzidziguri Amazon rara vez revela su ETA cuando se trata de lanzamientos.

@ rati-dzidziguri Entiendo y agradezco que quiera una ETA para que pueda planificar en consecuencia. En realidad, es por esa razón que generalmente no damos una ETA porque nos esforzamos mucho en no hacer promesas que no estamos 100% seguros de poder cumplir. Odiaría darte una ETA y tú haces tu hoja de ruta en base a eso y luego extrañaré esa ETA que esperabas que echara a perder todos tus planes.

Por ahora, si realmente necesita características de .NET Core 3.1, le sugiero que use .NET Core 3.1 como un tiempo de ejecución personalizado de Lambda que se explica aquí (excepto las referencias de cambio de .NET Core 3.0 a .NET Core 3.1). Luego, cuando llegue el soporte nativo de .NET Core 3.1, tendrá una migración muy simple de cambiar algunas configuraciones en su función Lambda.

@normj Una razón que me hizo decidir que no puedo usar la función de tiempo de ejecución personalizada con la clase 'LambdaEntry' es el aspecto de 'arquitectura monolítica' del enfoque de implementación. Cada solicitud de API viene a través de la única lambda de entrada y 'distribuida' a los controladores del proyecto ASP .net es lo que pretendía la estructura de tiempo de ejecución personalizada, que es definitivamente conveniente pero incluye desventajas estructurales para casos como el que quiero. Quiero que cada comando / solicitud de consulta se convierta en lambda cada uno. Desde entonces, puedo obtener una escalabilidad en la administración de paquetes de implementación que puedo dividir algunas funciones y administrar códigos en cualquier momento que desee.
Es por eso que estoy esperando que se admita el tiempo de ejecución oficial para poder construir un paquete de 'lambdas de propósito único' usando SAM escrito en una plantilla con la configuración 'runtime: .netcore 3.1'.

Por favor, dame un consejo si me equivoco :)

Definitivamente puede lograr múltiples funciones lambda a partir de una base de código utilizando Lambda Bootstrapper y la función de tiempo de ejecución personalizada.

Tengo un conjunto de 16 lambdas que se implementan desde una aplicación, en lugar de un "monolito".

Esto se logra mediante el uso de la variable de entorno _handler para elegir el método a usar en tiempo de ejecución, en lugar del mapeo uno a uno codificado que se muestra en el código de muestra de la publicación del blog.

Pienso en ella como una aplicación de consola que recibe un interruptor que le dice en qué acción "convertirse" cuando se inicia.

@martincostello
¡Gracias por la amable sugerencia! Puedo averiguar cómo será su caso. Es posible que haya colocado la lógica del conmutador en la clase Main o Startup para que se pueda determinar su funcionalidad en la primera etapa del tiempo de ejecución. Y puede resolver el problema del "único monolítico", por supuesto. Enfoque muy inteligente :)

Pero aún así, hay una consideración (si no muchas) en la que tengo que pensar, especialmente cuando me imagino trabajando en equipo. El uso de tiempo de ejecución personalizado y la determinación de la 'identidad funcional' en el inicio eliminarán la posibilidad de SAM. Por ejemplo, para nosotros, la puerta de enlace API no se puede definir mientras se implementa una lambda, lo que significa que tenemos que generar una manualmente para ella.
Sé que estoy exagerando aquí porque podemos hacer una configuración similar a SAM usando el script de arranque como se explica en el tutorial de AWS . Pero no nos satisfará por completo, ya que está usando un script de Linux, lo que significa
(1) puede ser vergonzoso para los recién llegados y, a veces, se convertirá en una curva de aprendizaje.
(2) descartará el beneficio de la expresividad de la plantilla sin servidor porque es literalmente un script, no un documento.

Creo que la plantilla sin servidor funciona como un semi-documento de cómo se ve el servidor y cómo funciona, que no solo se compartirá dentro de un equipo de desarrollo, sino incluso con algunos expertos no técnicos. y SAM es un concepto bien definido que en un futuro cercano las representaciones abstractas de una aplicación permitirán ser reutilizada por otro equipo utilizando lenguajes y plataformas totalmente diferentes. Sin lugar a dudas, estos aspectos todavía me motivan a seguir usando la función 'la plantilla sin servidor'.

Me vienen a la mente algunas fechas agradables para el lanzamiento de este, 25 de diciembre, 1 de enero;)

Felices fiestas a todos, desearía poder darles todo el tiempo de ejecución de .NET Core 3.1 Lambda para Navidad, pero creo que 2020 será un año emocionante para .NET y AWS.

Felices fiestas a todos, desearía poder darles todo el tiempo de ejecución de .NET Core 3.1 Lambda para Navidad, pero creo que 2020 será un año emocionante para .NET y AWS.

¡No te preocupes, disfruta de las vacaciones! ¡No puedo esperar a ver lo que tienes para nosotros en 2020! :)

esperando el soporte nativo de lambda en .NetCore3.1

Hay un límite de tamaño de disco para las funciones lambda. Creo que son 250 megas y cuando usamos el tiempo de ejecución personalizado, tenemos que enviar todos los ensamblajes principales de asp.net junto con nuestra aplicación. Alcancé ese límite cuando AWS estaba descomprimiendo mi paquete zip. Tuve que hacer una limpieza para reducir el espacio utilizado por mi aplicación. Cuando aparece el soporte nativo, no tenemos que empaquetar nuestra aplicación con ensamblados .core.

¿Hay alguna estimación sobre cuándo podemos esperar que se publique?

Estamos esperando actualizar a .Net core 3.1 hasta que haya soporte nativo para él.

¿Hay alguna estimación sobre cuándo podemos esperar que se publique?

Estamos esperando actualizar a .Net core 3.1 hasta que haya soporte nativo para él.

Si regresa y lee las respuestas, leerá de normj que no darán estimaciones.

Si regresa y lee las respuestas, leerá de normj que no darán estimaciones.

Mmmm normalmente, sí. Pero si aparece suficiente gente con horquillas, tal vez se dé un indicio de una fecha de lanzamiento para calmar los disturbios: sonrisa:

Recuerdo hace un tiempo cuando AWS pasó mucho tiempo preparando las imágenes nativas 2.1. Dijeron algo en el sentido de que rediseñaron el proceso para hacer que la implementación de versiones futuras sea más fácil y rápida de realizar. Ingrese NetCore 3.1 y casi dos meses después y todavía no está disponible :(

Sabes que Azure tenía esta imagen 3.1 disponible el día 1. Estoy empezando a ver por qué el gobierno de EE. UU. Elige a Azure como su proveedor de nube para JEDI.

Acabamos de recibir luz verde de nuestras partes interesadas para comenzar a apuntar a Azure como nuestro proveedor principal y dejar a AWS como respaldo. Con retrasos tontos como este, estoy seguro de que no somos los únicos.

Recuerdo hace un tiempo cuando AWS pasó mucho tiempo preparando las imágenes nativas 2.1. Dijeron algo en el sentido de que rediseñaron el proceso para hacer que la implementación de versiones futuras sea más fácil y rápida de realizar. Ingrese NetCore 3.1 y casi dos meses después y todavía no está disponible :(

Sabes que Azure tenía esta imagen 3.1 disponible el día 1. Estoy empezando a ver por qué el gobierno de EE. UU. Elige a Azure como su proveedor de nube para JEDI.

Acabamos de recibir luz verde de nuestras partes interesadas para comenzar a apuntar a Azure como nuestro proveedor principal y dejar a AWS como respaldo. Con retrasos tontos como este, estoy seguro de que no somos los únicos.

Estoy de acuerdo contigo. Mi organización no permite el tiempo de ejecución personalizado y estamos un poco atascados con 2.1. Cuando se trata de EF y Postgres junto con operaciones espaciales, es demasiado doloroso. Hemos estado esperando que esto se haga. Lástima que aún no esté hecho.

Recuerdo hace un tiempo cuando AWS pasó mucho tiempo preparando las imágenes nativas 2.1. Dijeron algo en el sentido de que rediseñaron el proceso para hacer que la implementación de versiones futuras sea más fácil y rápida de realizar. Ingrese NetCore 3.1 y casi dos meses después y todavía no está disponible :(

Sabes que Azure tenía esta imagen 3.1 disponible el día 1. Estoy empezando a ver por qué el gobierno de EE. UU. Elige a Azure como su proveedor de nube para JEDI.

Acabamos de recibir luz verde de nuestras partes interesadas para comenzar a apuntar a Azure como nuestro proveedor principal y dejar a AWS como respaldo. Con retrasos tontos como este, estoy seguro de que no somos los únicos.

¿JEDI usa .NET Core para suponer que es por eso que el gobierno eligió Azure?

Hola a todos,

Estoy trabajando activamente para brindar soporte para .NET Core 3.1 en Lambda. Se necesita algo de tiempo porque Microsoft hizo mucho trabajo en la forma en que construyen el tiempo de ejecución. Estoy trabajando para incorporar estos cambios para ofrecerles un tiempo de ejecución nativo.

@assyadh ¡ Gracias! No creo que los retrasos sean "tontos"; de hecho, preferiría esperar una versión sólida y funcional. Me encanta que AWS Lambda sea compatible con .NET Core y agradezco que continúe apoyándolo, como prometió.

No entiendo el impulso. No es que no tengamos un entorno LTS en este momento.

Obviamente, queremos usar los juguetes nuevos, pero el equipo de .NET en AWS solo tiene una cantidad fija de recursos y no pueden hacer todo a la vez.

Además, no anhelo la necesidad de apresurarme y actualizar el tiempo de ejecución de todas las funciones por temor a quedarme fuera de los términos de servicio.

Bien por ti @Kralizek, pero tu situación es tuya y no representa a los demás. No son realmente "juguetes nuevos" ahora, ¿verdad? .NET Core 3.x (y ASP.NET Core) tiene mejoras significativas sobre 2.x en una variedad de formas y los primeros usuarios están ansiosos por adoptar y aprovechar. Como dice @JamesQMurphy , también preferiríamos que el lanzamiento sea sólido.

Espero ver tu trabajo @assyadh.

"No entiendo el impulso".

No podemos usar .NET Core 3.1 compartido en una función lambda .NET Core 2.1, de hecho, ni siquiera podemos usar código .NET Core 2.2 compartido en una función lambda .NET Core 2.1, por lo que recientemente tuvimos que degradar a regañadientes nuestra componentes compartidos a .NET Core 2.1 para que sean compatibles con la función.

¿Se pueden compilar sus componentes compartidos en netstandard20? Entonces puedes compartirlos en netcore2 & 3

Si bien este hilo es específico de .NET 3.1, estoy seguro de que esta conversación exacta se reproducirá nuevamente cuando llegue .NET 5 (o 6 si ese será el próximo LTS).

Si bien se han citado algunos ejemplos específicos en los que no es posible (p. Ej., Archivo ZIP de código demasiado grande, política de la empresa), _ en general_ si desea utilizar el .NET Core "más reciente y mejor" en el futuro, puede hacerlo con un poca refactorización y el paquete de soporte de tiempo de ejecución personalizado.

En este momento, nos encontramos en un punto en el que la última versión _también resulta_ ser una versión LTS, lo que parece hacer que la necesidad de tenerla "lo antes posible" de Amazon parezca mucho más "urgente" que con, digamos, con soporte integrado 2.2 o 3.0.

En última instancia, se debe hacer un compromiso entre las nuevas funciones que se pueden usar en Lambda y el esfuerzo de desarrollo que se necesita para incorporar las soluciones PaaS.

.NET Core 3.1 ni siquiera estuvo disponible en Azure App Service de Microsoft durante 2-3 semanas después de su lanzamiento.

Si por lo general le gusta estar en la “vanguardia” lo antes posible, realizar una pequeña inversión en el uso del soporte de tiempo de ejecución personalizado a corto plazo le permitirá ejecutar potencialmente cualquier versión futura de .NET Core en Lambda en sus propias escalas de tiempo. Por supuesto, la compensación aquí, entre otras cosas, son paquetes más grandes, un poco más de código y la necesidad de hacer sus propios parches.

Con todo, hay un equilibrio y una compensación, y para el soporte integrado, de manera realista, siempre habrá un retraso en la disponibilidad porque el software lleva tiempo.

Dado que las versiones principales de .NET se realizarán en noviembre, el período de Navidad / vacaciones probablemente siempre tendrá un efecto en el tiempo que llevará hacer que estas cosas estén disponibles integradas en términos de tiempo y capacidad disponible del equipo Lambda.

Solo agrego mis pensamientos. Entiendo lo importante que es este comunicado y agradezco que nos lo cuente. Utilizo esa retroalimentación para impulsar la urgencia de nuestro lado. Como mencionó @martincostello, el momento en que salió .NET Core 3.1 no fue excelente debido a las vacaciones, sino también durante reInvent.

Fui el tipo que mencionó en el pasado para 2.1 que esperaba que la automatización que implementamos aceleraría el lanzamiento futuro. La automatización que puso @assyadh realmente nos ha ayudado, pero desafortunadamente las cosas han cambiado mucho desde que hicimos .NET Core 2.1. Parte de esto es cómo MS construye .NET Core y la otra parte es cómo funciona el servicio Lambda con el cambio a Amazon Linux 2.

Así que créanme que .NET Core 3.1 es @assyadh , para mí y para muchos otros la más alta prioridad.

Solo para verificar, ¿el trabajo para incorporarlo comienza una vez que Microsoft lanza las versiones preliminares en lugar de esperar la versión final? Eso probablemente reduciría el impacto de la Navidad y permitiría que se entregue antes una vez que salga el lanzamiento final, ya que solo necesitaría probarlo.

Utilizo esa retroalimentación para impulsar la urgencia de nuestro lado

Gracias por esto @normj. Aquí está mi $ 0.02, con la esperanza de que también ayude a su evangelización.

Como mencionó @martincostello, el momento en que salió .NET Core 3.1 no fue excelente debido a las vacaciones, sino también durante reInvent.

Como aludió @mungojam , .NET Core 3.1 estaba disponible en forma de vista previa a partir del 15 de octubre, más de un mes antes del lanzamiento. Además, es básicamente una versión de corrección de errores de 3.0: no conozco sus herramientas, pero me imagino que el trabajo exploratorio podría haber comenzado con 3.0, que se lanzó el 23 de septiembre y en vista previa durante todo el año . Vale la pena señalar que 3.1 recibió una fecha de lanzamiento estimada en el anuncio de lanzamiento de 3.0.

.NET Core 3.1 ni siquiera estuvo disponible en Azure App Service de Microsoft durante 2-3 semanas después de su lanzamiento.

.NET Core 3.1 estuvo disponible en Azure Functions el 17 de octubre , dos días después del lanzamiento de la versión preliminar 1.

Puede decir lo que quiera sobre la necesidad de cualquier empresa de tener 3.1 de inmediato, ya sea "de vanguardia", opciones de tiempo de ejecución personalizadas, etc., pero esto es realmente parte de un panorama más amplio sobre cuán seriamente AWS quiere apoyarnos .NET clientes. Si AWS, no el equipo de Norm, sino AWS en general, lo hubiera convertido en una prioridad, tengo que pensar que podrían haber estado al frente de esto, asegurándose de estar compitiendo con Azure.

Personalmente, realmente valoro tener opciones entre las ofertas en la nube que puedo elegir en función del mérito en lugar del dogma corporativo, y me encantaría que AWS dé el siguiente paso para mejorar el soporte de .NET.

Gracias @normj , @assyadh y cualquier otro que

Es posible que el equipo de .NET en AWS haya comenzado muy bien su viaje de preparación para .NET 3.1 LTS luego del lanzamiento de la versión 3.0. La cosa es que AWS tiende a guardar silencio sobre en qué están trabajando detrás de las cortinas. Esta falta de transparencia genera suposiciones. Creo que no estaría de más tener algún tipo de hoja de ruta, incluso si es provisional y las fechas están sujetas a cambios, etc.

Creo que el problema es que el equipo de AWS no quiere publicar ningún tipo de ETA y, por lo tanto, los desarrolladores se quedan en la oscuridad. @normj dice que eso se debe a que no quiere que nadie ni ninguna empresa haga planes futuros basados ​​en esas ETA. ¿No es el entendimiento general que una ETA es solo una estimación y que ninguna empresa debería hacer planes serios basados ​​en las estimaciones de otra empresa e incluso si lo hicieran, la empresa no puede culpar a AWS o estar enojada con ella por perder una ETA?

Una ETA tampoco es un día específico. Puede ser un mes. Un cuarto. Y deberíamos estar bien con cualquier ETA y estar bien si se pierde.

Mirando a
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html
parece que AWS desaprueba el tiempo de ejecución poco después del final de la vida útil de esa versión del tiempo de ejecución.

Debido a que las versiones de .NET Core LTS son compatibles durante 3 años, ya estamos
"dedicar el tiempo que podemos usar .NET Core 3.1 lambdas".
Por lo tanto, entiendo que las personas están hospitalizadas para obtener .NET core 3.1 en lambdas.
Por cierto, también preferiría un lanzamiento sólido como una roca y luego algo apresurado.

Supongo que estará disponible en el próximo mes o dos, pero algún compromiso de AWS,
incluso si es muy conservador, podría ser beneficioso para que los equipos planifiquen sus operaciones.

Otra cosa es que en esta época de OSS: ¿puede ayudar la comunidad .NET? Después de todo, estamos hablando de github.
¿Es este tiempo de ejecución "incorporado" un código cerrado?

Además, sería una característica ASESINANTE si el proceso de implementación tuviera un interruptor para hacer ReadyToRun y ​​otras características de compilación de AOT, por lo que los tiempos de inicio en frío se reducen seriamente.
Eso haría que .NET Core sea MUY atractivo en AWS Lambda, en mi opinión.

@normj y equipo:
gracias por hacer que .NET core sea excelente en AWS

Solo agrego mis pensamientos. Entiendo lo importante que es este comunicado y agradezco que nos lo cuente. Utilizo esa retroalimentación para impulsar la urgencia de nuestro lado.

Utilice esta publicación para impulsar la urgencia de su lado. Con eso en mente, aquí están mis dos centavos.

Solo para verificar, ¿el trabajo para incorporarlo comienza una vez que Microsoft lanza las versiones preliminares en lugar de esperar la versión final?

Pregunta: ¿Obtendremos una respuesta honesta a esta pregunta?

Parece que la respuesta es evidente por sí misma. Parece que la prioridad para .NET es el "nivel de pasatiempo" y no el "nivel empresarial" como debería ser.

He escuchado en alguna parte que 1) todo el material de Net Core se ha hecho de código abierto, y 2) existen algunos programas de adopción temprana que le permiten "comenzar a funcionar" en el momento del lanzamiento real. (consulte Google para obtener más detalles).

Estoy siendo gracioso aquí, pero la verdad es que todos los que siguen .NET lo saben, por lo que se suma a la autoevidencia en la que hablo.

Honestamente, después de los retrasos de 2.1 en el lanzamiento, tenía la esperanza de que los cambios realizados en ese entonces significaran que esta vez (3.1) tendríamos soporte para el nuevo marco no más de dos semanas después del lanzamiento real. Quiero decir, dentro de unas horas de lanzamiento sería ideal, pero dar algo de espacio para los toques / pulidos finales, dentro de dos semanas se siente bien.

Pero aquí estamos casi dos meses fuera y simplemente se siente "al nivel de un hobby".

@ rati-dzidziguri Entiendo y agradezco que quiera una ETA para que pueda planificar en consecuencia. En realidad, es por esa razón que generalmente no damos una ETA porque nos esforzamos mucho en no hacer promesas que no estamos 100% seguros de poder cumplir.

Este es un pensamiento "a nivel de hobby", como @abukres afirma con tanta elegancia:

Creo que el problema es que el equipo de AWS no quiere publicar ningún tipo de ETA y, por lo tanto, los desarrolladores se quedan en la oscuridad. @normj dice que eso se debe a que no quiere que nadie ni ninguna empresa haga planes futuros basados ​​en esas ETA. ¿No es el entendimiento general que una ETA es solo una estimación y que ninguna empresa debería hacer planes serios basados ​​en las estimaciones de otra empresa e incluso si lo hicieran, la empresa no puede culpar a AWS o estar enojada con ella por perder una ETA?

Una ETA tampoco es un día específico. Puede ser un mes. Un cuarto. Y deberíamos estar bien con cualquier ETA y estar bien si se pierde.

Creo que el hecho de que AWS perdiera el contrato JEDI con Azure debería haber sido suficiente para iniciar internamente algunas reuniones de priorización ya que, a primera vista, demuestra que .NET es un esfuerzo de "nivel empresarial" y debería tratarse como tal. En lugar de desperdiciar recursos tratando de "demandar" por la decisión, use esos recursos internamente para darle algo de amor a la comunidad .NET. Use esto como un momento para volver a priorizar .NET de modo que la próxima versión de .NET, AWS esté en la cima y sea evidente que están listos para comenzar a funcionar.

@normj , @martincostello y el resto de las abejas obreras de AWS, trabajando muy duro para proporcionar una oferta SOLID .NET, comprenda que estas quejas (de la comunidad) no son con usted per se, sino más bien con la cultura / política. que dictan el mandato de prioridad que se le ha dado con respecto a .NET. Utilice esta publicación para ayudar a lograr el soporte "a nivel empresarial".

Principalmente veo esto como una oportunidad perdida para que AWS brille. Imagínese si seguir una nueva versión de LTS fuera una alta prioridad. Qué declaración tan fuerte sería.

Cosas como esta hacen que los desarrolladores / arquitectos perdamos argumentos contra los tomadores de decisiones no técnicos cuando necesitamos decidir qué nube usar para el próximo proyecto. En estos días, en los que tanto Azure como AWS tienen en su mayoría el mismo costo y ofertas de funciones, las decisiones se toman más en base a la política y la percepción. No tengo nada que traer cuando dicen "han pasado X semanas / meses después del lanzamiento oficial y AWS todavía no está listo".

Nuevamente, como dice @ VagyokC4 , esto no es personal contra los empleados que hacen el trabajo real, sino más bien una llamada de atención para la alta gerencia de AWS.

Todos los que utilicen .NET Core 3.1 Lambda podrían considerar habilitar IL Trimming. Lo más probable es que reduzca el tamaño de sus archivos zip.
https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx

¿Está .NET core lambda 3.1 construido usando RuntimeAPI?
al aire libre, en github?
si no, ¿por qué no?

Todo lo que quiero para ... el día de San Valentín es compatibilidad con lambda .net core 3.1

Todo lo que quiero para ... el día de San Valentín es compatibilidad con lambda .net core 3.1

No se sale exactamente de la lengua, pero es tarareable:

No quiero mucho para Navidad San Valentín
Solo hay una cosa que necesito
No me importan los regalos
Debajo del árbol de AWS
Solo lo quiero para mi
Más de lo que podrías saber
Haz que mi deseo se haga realidad, oh
Todo lo que quiero para el Día de San Valentín es .NET Core 3.1 suppooooort ...

:sonrisa:

Microsoft incluye licencias Go Live hacia el final de su ciclo de vista previa cuando no introducirán cambios importantes. En ese momento, ofrecen soporte de producción para ese próximo lanzamiento. Mi recomendación sería esperar hasta que hagan un lanzamiento con una licencia Go Live y luego comenzar a trabajar en las herramientas. Con .NET Core 3.1 se incluyó en la versión preliminar 3, que se lanzó el 14/11. En este caso, el RTM ni siquiera llegó 3 semanas después, el 3 de diciembre, pero aún estaría más cerca de implementar las funciones cuando el RTM llegue y los clientes comiencen a generar expectativas.

Solo mis $ 0.02

Todo lo que quiero para ... el día de San Valentín es compatibilidad con lambda .net core 3.1

No se sale exactamente de la lengua, pero es tarareable:

No quiero mucho para ~ Navidad ~ San Valentín
Solo hay una cosa que necesito
No me importan los regalos
Debajo del árbol de AWS
Solo lo quiero para mi
Más de lo que podrías saber
Haz que mi deseo se haga realidad, oh
Todo lo que quiero para el Día de San Valentín es .NET Core 3.1 suppooooort ...

😁

+1 :)

¿Alguna actualización en el tiempo de ejecución de .NET Core 3.1 para Lambda?

Estamos comenzando un nuevo proyecto y nos inclinamos mucho por usar Lamba para la mayoría de los servidores sin servidor, pero ver cuánto tiempo lleva obtener una versión LTS compatible nos está haciendo repensar, posiblemente cambiando la arquitectura o el proveedor.

<Rant>
Es frustrante que la política de soporte de AWS Lambda Runtime sea muy estricta sobre un período de 30 días, cuando se solicitan características como esta por más de 30 días. Luego, mágicamente, un día, AWS implementará esta función y todos los demás tendrán que luchar para cambiar a .NET Core 3.1. Esto pone a la MAYORÍA de las organizaciones en una mala situación, ya que muchas veces se tarda más de un mes en reparar, probar e implementar algo en un entorno de producción. Personalmente, esta política me ha mordido en el trasero. Una vez (debido a las limitaciones de recursos y otras prioridades más altas) una empresa en la que estaba dejó escapar esta vez. No fue hasta 3 meses después que pudimos actualizar nuestras Lambdas a .NET Core 2.1. Una vez que intentamos implementar una lambda en particular con CloudFront, sucedió algo malo (¿qué? ¿Quién sabe porque los registros de CF son basura) y fue necesario revertirlo? Excepto que no había un tiempo de ejecución al que retroceder. Por lo tanto, LOCKED la implementación. Inmediatamente abrimos un boleto. 24 horas después, obtuvimos nuestra primera respuesta que fue "eliminar toda la pila y empezar de nuevo". Lo cual es una respuesta completamente ignorante considerando que habría tomado nuestras tablas de DynamoDb con la operación "delete". Estuvimos atrapados en ese retroceso durante más de 2 semanas y media. Finalmente, conseguimos un ingeniero de soporte que entendió las tecnologías de contenedores y nos ayudó a retroceder y luego se mantuvo en línea hasta que nuestro CloudFormation tuvo éxito. Lo que hizo bien, sin cambios en el primer intento. Por eso ahora odio la FQ, ya que es demasiado temperamental para usarla.
</Rant>

TL; DR; Es desagradable trabajar con la política de AWS Lambda Runtime Support y puede ponerlo en problemas.
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html

@CraigHead perdón por su experiencia frustrante, pero para ser claros independientemente de cuándo se

Sí, fue la migración de .NET Core 2.0 hacia adelante a .NET Core 2.1. Perdón por la perorata. 30 días es un poco apretado para algunos de nosotros. Observando la longitud total que podría correr una lambda sin un mantenimiento significativo y un control de calidad adicional.

mientras tanto, esto está sucediendo en el lado de Azure sin servidor
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

Mientras tanto, el equipo de AWS está trabajando en ello. Los comentarios sarcásticos no ayudan
ellos. Actualizarán este problema cuando esté listo.

El martes, 11 de febrero de 2020 a las 18:22, Rati Dzidziguri [email protected]
escribió:

mientras tanto, esto está sucediendo en el lado de Azure sin servidor

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

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAAZVJXAAYET4F7PFFOTO3LRCLUETA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVLOXWG43 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAAZVJQK3NBVXBZALM4V5KLRCLUETANCNFSM4JU5UTJA
.

Mi punto no fue hacer un comentario sarcástico, sino señalar que incluso MS anunció recientemente la disponibilidad de GA para 3.1, por lo que espero que AWS finalice pronto su trabajo en el soporte de 3.1.
.

mientras tanto, esto está sucediendo en el lado de Azure sin servidor
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

Teniendo en cuenta que es un lenguaje de MS, no es sorprendente que Azure haya superado a AWS para admitir esto.

Observando este hilo de cerca, con ganas de actualizar mis Lambdas de C #.

dotnet core 3.1.0 fue lanzado 2019-12-03
https://dotnet.microsoft.com/download/dotnet-core/3.1

estuvo disponible en Azure el 2020-01-23
https://azure.microsoft.com/en-us/updates/azure-functions-runtime-30-is-now-available/

estamos un poco menos de un mes adicional en comparación con Azure

Por cierto, todo el desarrollo del núcleo de .NET se realiza al aire libre en github
Por lo tanto, ser "lenguaje de MS" no debería tener mucho efecto.
¿O sugiere que los clientes de AWS que usan dotnet son mejores en Azure: P?

De todos modos, para cualquiera que esté escuchando en AWS:
estamos esperando 3.1 en Lambda, es importante para nosotros.

Por cierto, todo el desarrollo del núcleo de .NET se realiza al aire libre en github
Por lo tanto, ser "lenguaje de MS" no debería tener mucho efecto.
¿O sugiere que los clientes de AWS que usan dotnet son mejores en Azure: P?

Quiero decir, sería un poco vergonzoso que la plataforma en la nube de Microsoft no admita las nuevas funciones de su propio idioma. Para ser honesto, ¡estoy un poco sorprendido de que les haya llevado poco más de un mes y medio! Un poco más de comunicación interna quizás hubiera permitido que ambos se liberaran al mismo tiempo.

Creo que a AWS le está yendo bien con su soporte .Net, especialmente con los paquetes de desarrollo que se conectan a sus servicios, como CloudWatch + ILogging y su configuración de parámetros SSM, nos ha ayudado mucho.

Espero ver pronto la versión 3.1 :)

Desearía que hubiera una mejor implementación concreta de Cloudwatch de ILogger . Esto estaría mejor integrado en ServiceCollection / ServiceProvider cuando se usa Lambda SDK. La versión actual que se proporciona en el contexto de la solicitud y la clase LambdaLogger estática es básicamente imposible de realizar una prueba unitaria / verificar la salida del registro y conectar el .netcore ConsoleLogProvider predeterminado da

Desearía que hubiera una mejor implementación concreta de Cloudwatch de ILogger .

¿Ha probado https://github.com/aws/aws-logging-dotnet#aspnet -core-logging?

¿Cómo quieres que se vean tus registros @CraigHead?

Hemos utilizado Serilog y https://github.com/structured-log/structured-log en el pasado para generar buenos registros de consola y también registros basados ​​en JSON que se importaron a Seq. https://datalust.co/ esa fue la mejor manera para que obtengamos registros centrales en un formato realmente agradable.

@CraigHead Amazon.Lambda.Logging.AspNetCore es nuestra implementación para integrar el registro de Lambda en IServiceCollection. ¿Esa biblioteca no funciona para ti?

No recomendaría el paquete AWS.Logger.AspNetCore de ttps: //github.com/aws/aws-logging-dotnet#aspnet -core-logging para Lambda. Esa biblioteca usa un subproceso en segundo plano para enviar registros a CloudWatch Logs. El uso de un subproceso en segundo plano como ese no funciona bien con Lambda, que congela el entorno informático de Lambda tan pronto como regresa el controlador de funciones, lo que significa que es posible que el subproceso en segundo plano no tenga la oportunidad de vaciar los mensajes en cola.

Yo no sabía nada de esto. ¡Gracias por el consejo!
Me refería al Amazon.Lambda.Core.LambdaLogger en el SDK.
Definitivamente revisaré ese paquete ( Amazon.Lambda.Logging.AspNetCore ).

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

@claroagua
En lambda-land AFAIK no hay ningún evento que le notifique que la instancia actual dejará de procesarse o se terminará, por lo que su sugerencia dejará los eventos de registro almacenados en búfer sin vaciar (perdidos).

Por favor, no se apropie de este hilo para otras necesidades.
Este hilo se creó para proporcionar información sobre cuándo estará disponible .NET Core 3.1 en AWS Lambda.
Y para que AWS sepa que estamos ahí fuera y esperando.

¿Se incluirá la herramienta de prueba lambda en la versión 3.1? https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

Esa es mi intencion. El trabajo continúa en el simulacro de prueba-31 . La gran mejora en la rama 3.1 es que el código Lambda del usuario ahora se está ejecutando en un AssemblyLoadContext separado que debería solucionar muchos de los conflictos de versiones que los usuarios tenían con la versión actual. Estoy pensando en volver a portar la función AssemblyLoadContext a la versión 2.1.

Como nota al margen. Estoy debatiendo sobre convertir la interfaz de usuario básica en una aplicación Blazor del lado del servidor. ¿Alguien con más experiencia en Blazor tiene algún comentario sobre si es una buena o una mala idea?

Como nota al margen. Estoy debatiendo sobre convertir la interfaz de usuario básica en una aplicación Blazor del lado del servidor. ¿Alguien con más experiencia en Blazor tiene algún comentario sobre si es una buena o una mala idea?

Cualquier cosa de Blazor en este punto es una buena idea, ¡especialmente para aquellos de nosotros que rockeamos DotNet!

"interfaz de usuario básica": ¿esta es otra aplicación, no conectada a .NET Core 3.1 Lambdas?
Por cierto, no me importa blazor en absoluto

@petarrepac Esto se hizo en referencia a la herramienta de prueba AWS .NET Mock Lambda que enviamos para ayudar a depurar las funciones de .NET Core 2.1 Lambda. Aquí está la publicación de referencia https://aws.amazon.com/blogs/developer/debugging-net-core-aws-lambda-functions-using-the-aws-net-mock-lambda-test-tool/

Estoy en el proceso de actualizar la herramienta para .NET Core 3.1.

@normj
ah, no lo entendí, gracias
Es interesante pensar que nunca necesitamos una herramienta así.

desde nuestra perspectiva, lambda es un AspNetCore HttpApi básico al que puede llamar localmente y probar localmente
la única diferencia es el archivo / clase de punto de entrada que tiene menos de 50 líneas de código
Además, muchas cosas solo se pueden probar correctamente cuando se implementan en AWS:

• permisos
• forma de eventos JSON recibidos y contexto
• ...
  entonces, una combinación de:
• Buenas pruebas unitarias / de integración que se ejecutan localmente
• prueba http local
• fácil de implementar para probar el entorno de AWS
  puede llegar lejos

o me estoy perdiendo algún escenario obvio?

@petarrepac Uno de los grandes beneficios de usar el puente ASP.NET Core es que es realmente fácil de ejecutar localmente. Estoy de acuerdo en que la mejor práctica es usar pruebas unitarias / de integración, pero a menudo se necesitan pruebas rápidas ad hoc de la lógica de la aplicación y para eso es buena esta herramienta.

Gracias @normj. En lo que respecta a Blazor, podría ser un buen toque. Para el caso de uso de nuestro equipo, al menos probablemente se infrautilizaría.

Solo estamos en la interfaz de usuario el tiempo suficiente para enviar una carga útil y luego recorrer el código en VS.

Definitivamente puede lograr múltiples funciones lambda a partir de una base de código utilizando Lambda Bootstrapper y la función de tiempo de ejecución personalizada.

Tengo un conjunto de 16 lambdas que se implementan desde una aplicación, en lugar de un "monolito".

Esto se logra mediante el uso de la variable de entorno _handler para elegir el método a usar en tiempo de ejecución, en lugar del mapeo uno a uno codificado que se muestra en el código de muestra de la publicación del blog.

Pienso en ella como una aplicación de consola que recibe un interruptor que le dice en qué acción "convertirse" cuando se inicia.

@martincostello

Estoy teniendo problemas para lograr esto basándome en tu explicación. Tengo alrededor de 20 funciones Lambda en mi Functions.cs que están vinculadas a las definiciones correspondientes en mi serverless.template. Entiendo que pasaría una variable de entorno con cada definición para indicar a qué función llamar. La mayoría de estas funciones son de la firma:

public APIGatewayProxyResponse ThisLambdaFunction (solicitud APIGatewayProxyRequest, contexto ILambdaContext)
{

¿Cómo agrego soporte para diferentes firmas de funciones lambda, si tengo otras funciones que toman diferentes argumentos (además de APIGatewayProxyRequest) y diferentes tipos de retorno?

No descarrile el hilo.

@twopointzero He pasado días en Google buscando una solución para ejecutar múltiples funciones lambda usando el proyecto de tiempo de ejecución personalizado de .NET Core 3.1. No hay un hilo más relevante en Internet y estoy respondiendo a una publicación existente que brindó un rayo de esperanza de que hay una solución a mi problema.

No tener compatibilidad nativa con .NET Core 3.1 en AWS está dificultando la vida. Necesitamos actualizar a 3.1 para actualizar a la última EntityFramewore Core 3.1.2, que corrige los problemas que estamos viendo con la agrupación de conexiones en Aurora (PostgresSQL).

@normj Entiendo completamente la postura de no ETA, pero ¿puedes decirme si estamos cerca? <30 días?

@antsaia Con respeto, su comentario estaba relacionado con la implementación de un monolito distribuido utilizando soporte de tiempo de ejecución personalizado, no en relación con el soporte de AWS Lambda para .NET Core 3.1. Si no puede encontrar un hilo más relevante en Internet, le ruego que cree uno en lugar de descarrilar uno.

Para no descarrilar este hilo yo mismo, este es mi comentario final al respecto.

@normj ¿hay algún recurso disponible (blog, foro, etc.) donde podamos obtener información sobre el estado de la implementación del soporte de .net core 3.1?

Visito esta página a diario con la esperanza de obtener información nueva, pero obviamente no hay suficiente información (ya que no está destinada a ese uso). Sería mucho más fácil si tuviéramos algún tipo de actualización básica para poder planificar el futuro.

Como muchos aquí, nuestros planes para la entrega de funciones dependen en gran medida de si podemos usar 3.1 o si tenemos que desarrollarlo usando 2.1. En mi caso, 3.1 proporcionará soporte para System.Draw y esto tiene un gran impacto en la función en la que voy a trabajar.

Todo lo que quiero para ... el día de San Patricio es compatibilidad con lambda .net core 3.1

@ liam-sage, todo lo que pude encontrar fueron algunas publicaciones en el foro de Amazon que indicaban que estaría listo en el primer trimestre de 2020. https://forums.aws.amazon.com/thread.jspa?threadID=313806

@ liam-sage, todo lo que pude encontrar fueron algunas publicaciones en el foro de Amazon que indicaban que estaría listo en el primer trimestre de 2020. https://forums.aws.amazon.com/thread.jspa?threadID=313806

Esto significa que debe estar disponible en marzo. Estoy a la espera.

Hola, sé que no es completamente adecuado, pero puede actualizar sus propias lambdas a dotnetcore 3.1. Mientras tanto, mientras espera, le sugiero que cree muchas lambdas para escribir su propia plantilla dotnetcore. Hice eso por mi cuenta. Quería asegurarme de no tener que perder horas con el código repetitivo. Puede encontrar un ejemplo de plantilla aquí .

Y Vincent, ¿cómo lo hospedamos allí? usando tiempo de ejecución personalizado?
El jueves 5 de marzo de 2020 a las 7:40 p.m. Vincent van der Walt <
[email protected]> escribió:

Hola, sé que no es del todo adecuado, pero puedes conseguir tus propias lambdas.
actualizado a dotnetcore 3.1. Mientras tanto, mientras esperas, te sugeriría
si crea muchas lambdas para escribir su propia plantilla dotnetcore. yo hice
eso por mi cuenta. Quería asegurarme de no tener que perder horas con
código repetitivo. Puede encontrar un ejemplo de plantilla aquí.
https://github.com/vincentvanderwalt/aws-lambda-dotnetcore-3-template .

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AGIDH4OWUT7Y3HR3O5KARBDRF62V3A5CNFSM4JU5UTJKYY3PNVWWK3TUL52HSJKYY3PNVWWK3TUL52HS4DFZVOR5HG31 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AGIDH4PLKFSDLNBX2QVMG63RF62V3ANCNFSM4JU5UTJA
.

Sí, hace uso del tiempo de ejecución personalizado.

Puede ejecutarlo localmente en su máquina o implementarlo en aws.

F5 para local y dotnet lambda deploy-serverless para implementación en AWS

El archivo Léame explica cómo instalar la plantilla en su máquina local (es una plantilla dotnetcore)

Los tiempos de ejecución personalizados son geniales, pero todavía estoy esperando el soporte completo de AWS para .Net Core 3.1 para que las lambdas las utilicen en entornos de producción 😄

Cada vez que veo esto en mi bandeja de entrada, lo abro ansiosamente para ver si @normj tiene
anunció algo solo para encontrar una publicación que está al menos un poco fuera de lugar
tema. Alguien más le pidió a otros que no secuestraran el hilo y eso no
trabajó. ¿Alguien puede bloquear el hilo hasta que alguien esté listo para anunciar el
lanzamiento de soporte 3.1?

El viernes 6 de marzo de 2020 a las 7:13 a. M. Bartoszsiekanski [email protected]
escribió:

Los tiempos de ejecución personalizados son geniales, pero todavía estoy esperando el soporte completo de AWS
para .Net Core 3.1 para lambdas para usarlos en entornos de producción 😄

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAVUT3SNDR4L2ZL5J4KQYDDRGDSHBA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HSG43LVFVLOD
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAVUT3TBH3NIBMGB54EFCR3RGDSHBANCNFSM4JU5UTJA
.

Cree problemas separados para cualquier otra cosa que no sea discutir la compatibilidad con .NET Core 3.1. ¿Puedo cerrar este problema hasta que tengamos más noticias @normj ?

@ hounddog22030 No me di cuenta de que estaba 'secuestrando' el hilo. Estaba sugiriendo que, en lugar de preguntar constantemente si está listo, existen enfoques alternativos si la gente está desesperada por pasar a dotnetcore 3.1. El soporte oficial no personalizado en tiempo de ejecución estará listo cuando esté listo. La gente solo tiene que ser un poco más paciente o buscar un enfoque alternativo.

Si AWS admite la opción autocontenida en el comando del paquete dotnet lambda, las funciones lambda deben ser ejecutables independientemente de su versión de SDK. ¿Derecha? ¿Por qué no hacer eso en lugar de agregar soporte para cada versión de .NET Core?

Si AWS admite la opción autocontenida en el comando del paquete dotnet lambda, las funciones lambda deben ser ejecutables independientemente de su versión de SDK. ¿Derecha? ¿Por qué no hacer eso en lugar de agregar soporte para cada versión de .NET Core?

Acaba de describir la función de tiempo de ejecución personalizada de lambda

@aussiearef Eso funciona bien, pero el paquete autónomo incluye .Net Core en sí, que normalmente suma al menos 40 MB (comprimido) para un sitio web, lo que no deja mucho espacio para la aplicación y las dependencias en sí.

Cuando se usa la misma versión de .NET core, el tiempo de ejecución personalizado también es más lento (arranques en frío) que el tiempo de ejecución nativo. 3.1 agrega muchas mejoras de rendimiento, por lo que puede esperar el mismo nivel de rendimiento entre 3.1 personalizado totalmente optimizado y 2.1 nativo. Tengo la esperanza de que 3.1 nativo traerá mejoras significativas.

El primer trimestre terminará en 4 días, pero parece que no veremos 3.1 en lambda.
Espero que todos los miembros del equipo estén a salvo en esta época de pandemia y espero ver este lanzamiento en el segundo trimestre.

¡No pierdas la esperanza de que nos quedan unos días! Estamos todos bastante absortos esperando las implementaciones finales y otras actividades de última hora. Tenga en cuenta que todos conocemos el software y podría haber contratiempos de última hora.

De hecho, planeo comenzar un despliegue de las nuevas actualizaciones de herramientas del cliente pronto para asegurarme de que todo esté disponible una vez que se abra el tiempo de ejecución. Por lo tanto, si ve que se apagan nuevas actualizaciones del paquete NuGet, no asuma que el tiempo de ejecución está allí. Espere hasta que salga la publicación del blog y publicaré una actualización aquí.

Esas son noticias fantásticas. Gracias @normj

Esperamos la publicación y el lanzamiento del blog.

¡No pierdas la esperanza de que nos quedan unos días! Estamos todos bastante absortos esperando las implementaciones finales y otras actividades de última hora. Tenga en cuenta que todos conocemos el software y podría haber contratiempos de última hora.

De hecho, planeo comenzar un despliegue de las nuevas actualizaciones de herramientas del cliente pronto para asegurarme de que todo esté disponible una vez que se abra el tiempo de ejecución. Por lo tanto, si ve que se apagan nuevas actualizaciones del paquete NuGet, no asuma que el tiempo de ejecución está allí. Espere hasta que salga la publicación del blog y publicaré una actualización aquí.

Su paciencia frente a la actitud en este hilo es más que impresionante. ¡Gracias por trabajar en esto!

@normj feliz de

2 días más para el final y los dedos cruzados.

Y está fuera con 13 horas restantes en el trimestre 😅

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

Gracias a todos por vuestra paciencia. @raRaRa les dejo el honor de cerrar este número.

Excelente

El martes 31 de marzo de 2020 a las 20:06, Norm Johanson, [email protected] escribió:

Y está fuera con 13 horas restantes en el trimestre 😅

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

Gracias a todos por vuestra paciencia. @raRaRa https://github.com/raRaRa
Les dejo el honor de cerrar este tema.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-606785798 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AGUX3OUR6LN5CERIBTDHXP3RKIWLVANCNFSM4JU5UTJA
.

¡¡¡¡gracias!!!!

Y ... Darse de baja :-)

Gracias a todos los involucrados !!!

¡Gracias!

Y está fuera con 13 horas restantes en el trimestre 😅

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

Gracias a todos por vuestra paciencia. @raRaRa les dejo el honor de cerrar este número.

¡Buen trabajo!

Eso es AWS baby. ¡¡¡Eso es AWS !!!
No importa lo que pase, al final, lo logran.

Muchas gracias equipo !!!

Buenas noticias y muchas gracias @normj !!! A riesgo de sonar tonto y / o codicioso, ¿esto también significa intrínsecamente Powershell 7 también? Solo comprobando dos veces ...

¡ Buen trabajo

Aquí está el enlace al blog para aquellos que se desplazan hacia la parte inferior.
https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

increíble, ¡¡¡un millón de gracias por agregar soporte a dotnet core 3.1 !!!

@andyKalman Todavía no en PowerShell 7. Estoy haciendo algunos retoques finales en el módulo AWSLambdaPSCore y luego obtendré la versión 2.0.0 de AWSLambdaPSCore lanzada en la galería.

Agradezco la rápida respuesta @normj . Vi el número 607 después del hecho, es bueno ver que parece ser un seguimiento rápido. ¿Hay algún otro problema que rastrear para que pueda detener los comentarios aquí? :) Gracias de nuevo.

¡Felicitaciones!
¡Y gracias al equipo de AWS y .NET!
Muy apreciado.

¡Gracias a todos los que ayudaron a que esto sucediera! ¡Este es un gran lanzamiento y muestra que se hizo mucho trabajo! ¡Bonito! 🎉🥳

Gracias !! : aplaudir :: aplaudir :: tada :: tada:

Felicidades chicos, esperando la actualización.

¡Gracias!

Impresionante trabajo, con ganas de actualizar estas lambdas.

¡Buen trabajo! Gracias @normj 👏 👏

¡Gran equipo de trabajo!

Deseoso de saltar sobre los trabajadores de Lambda con las suscripciones de dotnet 3.1 Async Streams + AWS AppSync / GraphQL.
Equipo de AWS, ¡muchas, muchas gracias!

Dios mío, chicos, ustedes gobiernan! ¡Increíble! ¡Guau! 😄😄😄

¡GRACIAS!

@andyKalman Lancé la versión 2.0.0 del módulo AWSLambdaPSCore que ahora usa PowerShell 7. Estoy planeando publicar una publicación de blog sobre el soporte de PS7 pero actúa de la misma manera que el soporte existente de PowerShell 6 solo usa 7.

@andyKalman Lancé la versión 2.0.0 del módulo AWSLambdaPSCore que ahora usa PowerShell 7. Estoy planeando publicar una publicación de blog sobre el soporte de PS7 pero actúa de la misma manera que el soporte existente de PowerShell 6 solo usa 7.

¿La nueva versión de AWSLambdaPSCore actualiza alguna de las configuraciones dentro de mis funciones Lambda existentes si las publico con la nueva versión? ¿Apuntará hacia dotnet3.1 y ps7?

@ tr33squid Sí, si implementa con 2.0.0, usará .NET Core 3.1 y PS7

¡Muchas gracias y excelente trabajo, equipo de AWS!

Hola a todos,

Estoy trabajando activamente para brindar soporte para .NET Core 3.1 en Lambda. Se necesita algo de tiempo porque Microsoft hizo mucho trabajo en la forma en que construyen el tiempo de ejecución. Estoy trabajando para incorporar estos cambios para ofrecerles un tiempo de ejecución nativo.

Gracias al equipo central de AWS-Lambda .NET

Hola,
Recibo este error al intentar ejecutar AWS-Lambda
No fue posible encontrar ninguna versión de marco compatible.
No se encontró el marco especificado 'Microsoft.AspNetCore.App', versión '3.1.0'.
alguna sugerencia ??

Hola,
Recibo este error al intentar ejecutar AWS-Lambda
No fue posible encontrar ninguna versión de marco compatible.
No se encontró el marco especificado 'Microsoft.AspNetCore.App', versión '3.1.0'.
alguna sugerencia ??

Necesita instalar el SDK 3.1.0.

Creo que Microsoft.AspNetCore.App debería eliminarse de su proyecto
dependencias, ya no se necesitan para Core 3.1.0, tuve que eliminarlo para
construir e implementar el servicio que actualicé desde 2.1.

El viernes 24 de abril de 2020 a las 3:24 a.m. Gregory Lyons [email protected]
escribió:

Hola,
Recibo este error al intentar ejecutar AWS-Lambda
No fue posible encontrar ninguna versión de marco compatible.
El marco especificado 'Microsoft.AspNetCore.App', versión '3.1.0' fue
extraviado.
alguna sugerencia ??

Necesita instalar el SDK 3.1.0.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-618850277 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA
.

-
Mejor,
Jorge

George Taskos
Arquitecto Senior de Soluciones

WeAre8
230 Park Avenue, 3er piso Oeste
Nueva York, NY 10169
(917) 717-9067
weare8.com

Entrada privada,
71 Vanderbilt Ave
3er piso

Creo que Microsoft.AspNetCore.App debería eliminarse de las dependencias de su proyecto, ya no es necesario para Core 3.1.0, tuve que eliminarlo para construir e implementar el servicio que actualicé desde 2.1.
...
El viernes 24 de abril de 2020 a las 3:24 a.m. Gregory Lyons @ . * > escribió: Hola, recibo este error al intentar ejecutar AWS-Lambda. No fue posible encontrar ninguna versión de marco compatible. No se encontró el marco especificado 'Microsoft.AspNetCore.App', versión '3.1.0'. alguna sugerencia ?? Necesita instalar el SDK 3.1.0. - Estás recibiendo esto porque estás suscrito a este hilo. Responda a este correo electrónico directamente, véalo en GitHub < # 554 (comentario) > o cancele la suscripción https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA .
- Saludos cordiales, George George Taskos Arquitecto sénior de soluciones WeAre8 230 Park Avenue, 3th fl. West New York, NY 10169 (917) 717-9067 weare8.com Entrada privada, 71 Vanderbilt Ave 3er piso

Gracias por su respuesta,
En realidad, este error se debió a mi tonto error. Olvidé eliminar el tiempo de ejecución: dotnetcore2.1 en mi serverless.yml. Ahora problema resuelto.

¿Alguien hace algún punto de referencia / comparaciones actualizado sobre esto? Todo lo que puedo encontrar son viejos con un tiempo de ejecución personalizado.

¿Alguien hace algún punto de referencia / comparaciones actualizado sobre esto? Todo lo que puedo encontrar son viejos con un tiempo de ejecución personalizado.

Aqui hay uno bueno.
https://medium.com/@zaccharles/a -close-look-at-net-core-3-1-on-aws-lambda-9ccec4dd96be

Además, mi experiencia personal al actualizar un lambda complejo 2.1 a 3.1 en un tamaño lambda de 512mb vio casi exactamente el mismo rendimiento (arranque en frío y en caliente). Tanto la lambda 2.1 como la 3.1 usan la capa lambda, publicación optimizada, newtonsoft (podría ver una mejora de rendimiento con Microsoft json en 3.1), compilación por niveles desactivada y RTR para 3.1.

Según mis métricas, parece ganar un ligero rendimiento con el tiempo de ejecución de dotnet 3.1, pero pierde rendimiento en la inicialización de Amazon Linux 2 y dotnet 3.1. (2.1 usa Amazon Linux 1.) Haciendo ganancias.