Aws-lambda-dotnet: Выпущен .NET Core 3.1 (LTS)

Это LTS и будет поддерживаться. Просто потребуется время, чтобы подготовить .NET Core 3.1 для Lambda и развернуть.

Это LTS и будет поддерживаться. Просто потребуется время, чтобы подготовить .NET Core 3.1 для Lambda и развернуть ее.

Если я могу чем-то помочь, пожалуйста, дайте мне знать.

Будет ли ускорено время холодного старта?

.NET Core 3.1 имеет некоторые функции, такие как компиляция AOT.

• PublishReadyToRun
• Опубликовать

@normj, должны ли люди подписываться на эту проблему для получения обновлений, или есть еще одна проблема .NET Core 3.1, за которой мы должны следить для прогресса?

Мы можем использовать эту проблему для отслеживания обновлений. К сожалению, я, вероятно, не смогу предоставить большую часть обновлений статуса, пока они не будут выпущены.

Будет ли ускорено время холодного старта?

.NET Core 3.1 имеет некоторые функции, такие как компиляция AOT.

• PublishReadyToRun
• Опубликовать

Если ответ на комментарий утвердительный, можно ли будет запустить и протестировать «скомпилированную лямбду» из локальной среды? Я бы с радостью установил для него среду linux :)

Есть обновления здесь?

@ rati-dzidziguri

Как указано выше из @normj

Мы можем использовать эту проблему для отслеживания обновлений. К сожалению, я, вероятно, не смогу предоставить большую часть обновлений статуса, пока они не будут выпущены.

@beeradmoore
Мой вопрос касался расчетного времени прибытия. Было бы полезно знать расчетное время прибытия, так как мы могли бы подготовиться соответствующим образом.

@ rati-dzidziguri Amazon редко раскрывает свое расчетное время прибытия, когда дело доходит до релизов.

@ rati-dzidziguri Я понимаю и ценю, что вы хотите получить расчетное время прибытия, так что вы можете планировать соответственно. На самом деле, именно по этой причине мы обычно не даем ETA, потому что мы очень стараемся не давать обещаний, которые не на 100% уверены, что сможем их выполнить. Мне бы очень не хотелось давать вам ETA, и вы составляете свою дорожную карту на основе этого, и тогда мы пропустим то ETA, которое, как вы ожидали, разрушило все ваши планы.

На данный момент, если вам действительно нужны функции .NET Core 3.1, я предлагаю использовать .NET Core 3.1 в качестве настраиваемой среды выполнения Lambda, которая объясняется здесь (за исключением ссылок на изменение с .NET Core 3.0 на .NET Core 3.1). Затем, когда появится встроенная поддержка .NET Core 3.1, у вас будет очень простая миграция, изменив несколько настроек вашей лямбда-функции.

@normj Одна из причин заставила меня решить, что я не могу использовать настраиваемую функцию времени выполнения с классом LambdaEntry, - это аспект монолитной архитектуры подхода к реализации. Каждый запрос API проходит через лямбда-выражение с единственной записью и «распределяется» по контроллерам проекта ASP .net - это то, что предназначалась для настраиваемой структуры времени выполнения, что, безусловно, удобно, но включает в себя структурный недостаток для таких случаев, как я. Я хочу, чтобы каждый запрос команды / запроса стал лямбда-выражением. С тех пор я могу получить масштабируемость по управлению пакетами развертывания, я могу разделить некоторые функции и управлять кодами в любое время, когда захочу.
Вот почему я жду, когда будет поддерживаться официальная среда выполнения, чтобы я мог создать связку «одноцелевых лямбда-выражений» с использованием SAM, написанного в шаблоне с конфигурацией «runtime: .netcore 3.1».

Пожалуйста, дайте мне совет, если я ошибаюсь :)

Вы определенно можете создать несколько лямбда-функций из одной базы кода, используя Lambda Bootstrapper и настраиваемую функцию времени выполнения.

У меня есть набор из 16 лямбд, которые развертываются из одного приложения, а не из «монолита».

Это достигается за счет использования переменной среды _handler для выбора метода, используемого во время выполнения, а не жестко заданного однозначного сопоставления, показанного в образце кода сообщения в блоге.

Я думаю об этом как о консольном приложении, которое получает переключатель, который сообщает ему, каким действием «стать» при запуске.

@martincostello
Спасибо за любезное предложение! Я могу понять, как может выглядеть ваш чехол. Вы могли бы поместить логику переключения в класс Main или Startup, чтобы можно было определить ее функциональность на первом этапе выполнения. И это, конечно, может решить проблему «только монолитности». Очень умный подход :)

Но все же есть одно (если не много) соображение, о котором я должен подумать, особенно когда я представляю себе работу в команде. Использование настраиваемой среды выполнения и определение «функциональной идентичности» при запуске избавит от возможности SAM. В качестве простого примера, шлюз API не может быть определен при развертывании лямбда-выражения, что означает, что мы должны вручную сгенерировать его для него.
Я знаю, что преувеличиваю здесь, потому что мы можем сделать что-то похожее на SAM конфигурацию, используя сценарий начальной загрузки, как объясняется в учебнике aws . Но это нас не полностью удовлетворит, так как он использует скрипт linux, что означает
(1) это может быть неудобно для новичков, а иногда это превращается в кривую обучения.
(2) он откажется от выразительности бессерверного шаблона, потому что это буквально сценарий, а не документ.

Я думаю, что бессерверный шаблон работает как полудокумент о том, как выглядит сервер и как он работает, который будет передан не только команде разработчиков, но даже некоторым проницательным нетехническим специалистам. SAM - это четко определенная концепция, которая в ближайшем будущем позволит использовать абстрактные представления приложения другой командой, использующей совершенно другие языки и платформы. Эти аспекты по-прежнему, несомненно, побуждают меня использовать функцию «бессерверного шаблона».

Впереди несколько хороших дат выпуска этого, 25 декабря, 1 января приходят на ум;)

Всем счастливых праздников, я хотел бы дать вам всю среду выполнения .NET Core 3.1 Lambda на Рождество, но я думаю, что 2020 год будет захватывающим для .NET и AWS.

Всем счастливых праздников, я хотел бы дать вам всю среду выполнения .NET Core 3.1 Lambda на Рождество, но я думаю, что 2020 год будет захватывающим для .NET и AWS.

Не беспокойтесь, наслаждайтесь праздником! Не могу дождаться, чтобы увидеть, что вы приготовили для нас в 2020 году! :)

ждем встроенной поддержки лямбда на .NetCore3.1

Для лямбда-функций существует ограничение на размер диска. Я думаю, это 250 мегабайт, и при использовании настраиваемой среды выполнения мы должны отправлять все основные сборки asp.net вместе с нашим приложением. Я достиг этого предела, когда AWS распаковывал мой zip-пакет. Мне пришлось сделать некоторую очистку, чтобы уменьшить пространство, используемое моим приложением. Когда появится встроенная поддержка, нам не нужно упаковывать наше приложение с помощью сборок .core.

Есть ли какие-нибудь оценки того, когда мы можем ожидать этого релиза?

Мы ждем обновления до .Net core 3.1, пока для него не появится встроенная поддержка.

Есть ли какие-нибудь оценки того, когда мы можем ожидать этого релиза?

Мы ждем обновления до .Net core 3.1, пока для него не появится встроенная поддержка.

Если вы вернетесь и прочитаете ответы, вы прочитаете из normj, что они не дадут никаких оценок.

Если вы вернетесь и прочитаете ответы, вы прочитаете из normj, что они не дадут никаких оценок.

Мммм нормально - да. Но если появится достаточное количество людей с вилками, то, возможно, будет дан намек на дату выпуска, чтобы подавить волнения: grin:

Я помню время, когда AWS долго готовила образы в машинном коде 2.1. Они сказали что-то о том, что они переработали процесс, чтобы упростить развертывание будущих версий и ускорить их работу. Войдите в NetCore 3.1 и почти два месяца спустя, а он все еще недоступен :(

Вы знаете, что в Azure был доступен этот образ 3.1. День 1. Я начинаю понимать, почему правительство США выбрало Azure в качестве поставщика облачных услуг для JEDI.

Мы только что получили зеленый свет от заинтересованных сторон, чтобы начать нацеливаться на Azure в качестве нашего основного поставщика, оставив AWS в качестве резервного. Я уверен, что с такими глупыми задержками мы не единственные.

Я помню время, когда AWS долго готовила образы в машинном коде 2.1. Они сказали что-то о том, что они переработали процесс, чтобы упростить развертывание будущих версий и ускорить их работу. Войдите в NetCore 3.1 и почти два месяца спустя, а он все еще недоступен :(

Вы знаете, что в Azure был доступен этот образ 3.1. День 1. Я начинаю понимать, почему правительство США выбрало Azure в качестве поставщика облачных услуг для JEDI.

Мы только что получили зеленый свет от заинтересованных сторон, чтобы начать нацеливаться на Azure в качестве нашего основного поставщика, оставив AWS в качестве резервного. Я уверен, что с такими глупыми задержками мы не единственные.

Я согласен. Моя организация не поддерживает настраиваемую среду выполнения, и мы как бы застряли на версии 2.1. Когда дело касается EF и Postgres, а также пространственных операций, это слишком больно. Мы ждали этого. Жаль, что это еще не сделано.

Я помню время, когда AWS долго готовила образы в машинном коде 2.1. Они сказали что-то о том, что они переработали процесс, чтобы упростить развертывание будущих версий и ускорить их работу. Войдите в NetCore 3.1 и почти два месяца спустя, а он все еще недоступен :(

Вы знаете, что в Azure был доступен этот образ 3.1. День 1. Я начинаю понимать, почему правительство США выбрало Azure в качестве поставщика облачных услуг для JEDI.

Мы только что получили зеленый свет от заинтересованных сторон, чтобы начать нацеливаться на Azure в качестве нашего основного поставщика, оставив AWS в качестве резервного. Я уверен, что с такими глупыми задержками мы не единственные.

Использует ли JEDI .NET Core, чтобы сделать предположение, почему правительство выбрало Azure?

Всем привет,

Я активно работаю над внедрением поддержки .NET Core 3.1 в Lambda. Это займет некоторое время, потому что Microsoft проделала большую работу по созданию среды выполнения. Я работаю над внесением этих изменений, чтобы предоставить вам родную среду выполнения.

@assyadh Спасибо! Я не считаю задержки «глупыми»; на самом деле я бы скорее дождался солидной рабочей версии. Мне нравится, что AWS Lambda поддерживает .NET Core, и я ценю, что вы продолжаете поддерживать его, как и обещали.

Я не понимаю этого побуждения. Дело не в том, что у нас сейчас нет среды LTS.

Очевидно, мы хотим использовать новые игрушки, но у команды .NET в AWS есть только фиксированный объем ресурсов, и они не могут делать все сразу.

Кроме того, я не хочу спешить и обновлять время выполнения всех функций из-за опасений, что сроки обслуживания выйдут из строя.

Молодец, @Kralizek, но ваша ситуация принадлежит вам и не представляет других. Это уже не совсем «новые игрушки». .NET Core 3.x (и ASP.NET Core) имеет значительные улучшения по сравнению с 2.x во многих отношениях, и ранние последователи стремятся принять и использовать. Как говорит @JamesQMurphy , мы также предпочли бы, чтобы релиз был прочным.

Я с нетерпением жду ваших работ @assyadh.

«Я не понимаю этого побуждения».

Мы не можем использовать общий .NET Core 3.1 в лямбда-функции .NET Core 2.1, на самом деле мы даже не можем использовать общий код .NET Core 2.2 в лямбда-функции .NET Core 2.1, поэтому нам недавно пришлось неохотно понизить нашу общие компоненты в .NET Core 2.1, чтобы обеспечить их поддержку в функции.

Можно ли скомпилировать ваши общие компоненты в netstandard20? Затем вы можете поделиться ими в netcore2 и 3

Хотя этот поток специфичен для .NET 3.1, я уверен, что именно этот разговор будет воспроизведен снова, когда появится .NET 5 (или 6, если это будет следующий LTS).

Хотя были приведены некоторые конкретные примеры, где это невозможно (например, слишком большой ZIP-файл с кодом, политика компании), _ в целом_, если вы хотите использовать «последнюю и лучшую» версию .NET Core в будущем, вы можете сделать это с помощью небольшой рефакторинг и специальный пакет поддержки времени выполнения.

В это время мы просто оказались в точке, где последний релиз _ также бывает_ LTS-релизом, что, кажется, делает необходимость получить его «как можно скорее» от Amazon гораздо более «срочным», чем это было с, скажем, имея встроенную поддержку 2.2 или 3.0.

В конечном итоге необходимо найти компромисс между новыми функциями, которые можно использовать в Lambda, и усилиями по разработке, которые необходимо вложить в решения PaaS.

.NET Core 3.1 даже не был доступен в службе приложений Microsoft Azure в течение 2-3 недель после выпуска.

Если вы обычно хотите быть на «переднем крае» как можно скорее, небольшие вложения в использование поддержки настраиваемой среды выполнения в краткосрочной перспективе позволят вам потенциально запускать любую будущую версию .NET Core в Lambda в ваши собственные сроки. Конечно, компромисс здесь, помимо прочего, заключается в более крупных пакетах, немного большем количестве кода и необходимости вносить собственные исправления.

Во всем есть баланс и компромисс, а для встроенной поддержки реально всегда будет отставание в доступности, потому что программное обеспечение требует времени.

Поскольку основные выпуски .NET выходят в ноябре, период Рождества / праздников, вероятно, всегда будет влиять на то, сколько времени займет создание этих встроенных вещей с точки зрения времени и доступной мощности команды Lambda.

Просто добавляю свои мысли. Я понимаю, насколько этот выпуск очень важен, и признателен за то, что вы нам рассказали. Я использую эту обратную связь, чтобы повысить срочность на нашей стороне. Как упомянул @martincostello, время выхода .NET Core 3.1 было не лучшим из-за праздников, но также и во время reInvent.

Я был тем парнем, который упоминал в прошлом для 2.1, что я надеялся, что автоматизация, которую мы внедрили, ускорит будущую версию. Автоматизация, которую внедрил @assyadh , действительно помогла нам, но, к сожалению, с

Поэтому, пожалуйста, поверьте мне, что .NET Core 3.1 - это высший приоритет для

Просто чтобы проверить, начинается ли работа по его внедрению сразу после выпуска предварительных версий Microsoft, а не в ожидании финальной версии? Это, по-видимому, уменьшит влияние Рождества и позволит доставить его раньше, как только выйдет финальный релиз, поскольку ему просто нужно будет протестировать.

Я использую этот отзыв, чтобы повысить срочность на нашей стороне

Спасибо за это @normj. Вот мои 0,02 доллара в надежде, что они также помогут вашей евангелизации.

Как упомянул @martincostello, время выхода .NET Core 3.1 было не лучшим из-за праздников, но также и во время reInvent.

Как упоминал @mungojam , .NET Core 3.1 был доступен в форме предварительного просмотра с 15 октября, то есть за месяц до выпуска. Кроме того, это в основном версия 3.0 с исправлением ошибок - я не знаю ваших инструментов, но предполагаю, что исследовательская работа могла быть начата с версии 3.0, выпущенной 23 сентября и находящейся в предварительной версии в течение всего года . Стоит отметить, что приблизительная дата выпуска 3.1 была указана в объявлении о выпуске 3.0.

.NET Core 3.1 даже не был доступен в службе приложений Microsoft Azure в течение 2-3 недель после выпуска.

.NET Core 3.1 был доступен в Функциях Azure 17 октября , через два дня после выпуска Preview 1.

Вы можете сказать, что хотите, о том, что любой компании необходимо сразу иметь 3.1, будь то «передовой край», настраиваемые параметры времени выполнения и т. Д., Но это действительно часть более широкой картины того, насколько серьезно AWS хочет поддерживать нас. .NET клиенты. Если бы AWS - не команда Норма, а AWS в целом - сделала это своим приоритетом, я должен думать, что они могли бы опередить это, убедившись, что они конкурируют с Azure.

Лично я очень ценю наличие вариантов среди облачных предложений, которые я могу выбрать на основе достоинств, а не корпоративных догм, и мне бы хотелось, чтобы AWS сделала следующий шаг в улучшении поддержки .NET.

Спасибо @normj , @assyadh и всем, кто работает над этим, за ваши усилия.

Возможно, команда .NET в AWS очень хорошо начала свой путь подготовки для .NET 3.1 LTS после выпуска предварительной версии 3.0. Дело в том, что AWS, как правило, умалчивает о том, над чем они работают за кулисами. Это отсутствие прозрачности порождает предположения. Думаю, не помешало бы иметь своего рода дорожную карту, даже если она предварительная, даты могут быть изменены и т. Д.

Я думаю, проблема в том, что команда AWS не хочет разглашать ETA, и поэтому разработчики остаются в неведении. @normj говорит, что это потому, что он не хочет, чтобы кто-либо или какая-либо компания строили планы на будущее на основе этих ETA. Разве не существует общего понимания того, что ETA - это всего лишь оценка, и ни одна компания не должна строить серьезные планы на основе оценок другой компании, и даже если они это сделали, компания не может обвинять AWS или злиться на нее за пропущенное ETA?

Расчетное время прибытия также не является конкретным днем. Это может быть месяц. Четверть. И мы должны быть в порядке с любым расчетным временем прибытия и в порядке, если его пропустили.

Смотря на
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html
похоже, что AWS прекращает поддержку среды выполнения вскоре после окончания срока службы этой версии среды выполнения.

Поскольку версии .NET Core LTS поддерживаются в течение 3 лет, мы уже
«тратя время, мы можем использовать лямбды .NET Core 3.1».
Поэтому я понимаю, что люди хотят получить .NET core 3.1 на лямбдах в стационаре.
Кстати, я бы также предпочел рок-твердый релиз, тогда что-то торопится.

Я предполагаю, что он будет доступен в ближайшие месяц или два, но некоторые обязательства со стороны AWS,
даже если очень консервативный подход может быть полезным для команд при планировании своей деятельности.

Другое дело, что в наше время OSS: может ли сообщество .NET помочь? Мы ведь говорим на гитхабе.
Является ли эта "встроенная" среда исполнения закрытым кодом?

Кроме того, это было бы функцией KILLER, если бы в процессе развертывания был переключатель для выполнения ReadyToRun и других функций компиляции AOT, поэтому время холодного запуска серьезно сокращалось.
Это сделало бы .NET Core ОЧЕНЬ привлекательной для AWS Lambda, IMO.

@normj и команда:
спасибо за то, что сделали ядро ​​.NET отличным для AWS

Просто добавляю свои мысли. Я понимаю, насколько этот выпуск очень важен, и признателен за то, что вы нам рассказали. Я использую эту обратную связь, чтобы повысить срочность на нашей стороне.

Пожалуйста, используйте этот пост, чтобы подтолкнуть срочность к вам. Имея это в виду, вот мои два пенни.

Просто чтобы проверить, начинается ли работа по его внедрению сразу после выпуска предварительных версий Microsoft, а не в ожидании финальной версии?

Вопрос: Получим ли мы честный ответ на этот вопрос?

Похоже, ответ очевиден. Похоже, что приоритетом для .NET является «уровень хобби», а не «уровень предприятия», как должно быть.

Я где-то слышал, что 1) весь материал Net Core был сделан с открытым исходным кодом, и 2) существуют некоторые ранние программы, которые позволяют вам "взяться за дело" после фактического выпуска. (подробности см. в Google.)

Я здесь забавный, но правда в том, что это знают все, кто следит за .NET, так что это добавляет самоочевидности, о которой я говорю.

Честно говоря, после задержки выпуска 2.1 я надеялся, что внесенные тогда изменения означают, что на этот раз (3.1) у нас будет поддержка новой структуры не более чем через две недели после фактического выпуска. Я имею в виду, что в течение нескольких часов после выпуска было бы идеально, но дать немного места для последних штрихов / полировки, в течение двух недель кажется правильным.

Но вот у нас почти два месяца, и это просто похоже на хобби.

@ rati-dzidziguri Я понимаю и ценю, что вы хотите получить расчетное время прибытия, так что вы можете планировать соответственно. На самом деле, именно по этой причине мы обычно не даем ETA, потому что мы очень стараемся не давать обещаний, которые не на 100% уверены, что сможем их выполнить.

Это мышление «на уровне хобби», как элегантно утверждает @abukres :

Я думаю, проблема в том, что команда AWS не хочет разглашать ETA, и поэтому разработчики остаются в неведении. @normj говорит, что это потому, что он не хочет, чтобы кто-либо или какая-либо компания строили планы на будущее на основе этих ETA. Разве не существует общего понимания того, что ETA - это всего лишь оценка, и ни одна компания не должна строить серьезные планы на основе оценок другой компании, и даже если они это сделали, компания не может обвинять AWS или злиться на нее за пропущенное ETA?

Расчетное время прибытия также не является конкретным днем. Это может быть месяц. Четверть. И мы должны быть в порядке с любым расчетным временем прибытия и в порядке, если его пропустили.

Я думаю, что тот факт, что AWS потерял контракт JEDI с Azure, должен был быть достаточным для внутреннего начала некоторых встреч по определению приоритетов, поскольку на первый взгляд это доказывает, что .NET - это предприятие «корпоративного уровня» и к нему следует относиться как к такому. Вместо того, чтобы тратить ресурсы, пытаясь «подать в суд» из-за этого решения, используйте эти ресурсы внутри компании, чтобы подарить сообществу .NET немного любви. Воспользуйтесь этим моментом, чтобы изменить приоритеты .NET, чтобы в следующем выпуске .NET AWS находился на его вершине и демонстрировал самоочевидность, что они готовы взяться за дело.

@normj , @martincostello и остальные рабочие пчелы там, в AWS, очень усердно работают над предложением SOLID .NET, пожалуйста, поймите, что эти (сообщества) жалобы не с вами сами по себе, а больше с культурой / политикой которые диктуют приоритетный мандат, данный вам в отношении .NET. Пожалуйста, используйте этот пост, чтобы получить поддержку на уровне предприятия.

В основном я рассматриваю это как упущенную возможность для успеха AWS. Представьте себе, если бы слежение за новым выпуском LTS было бы первоочередной задачей. Какое сильное заявление это было бы.

Подобные вещи заставляют нас, разработчиков / архитекторов, терять аргументы против лиц, принимающих решения нетехнического характера, когда нам нужно решить, какое облако использовать для следующего проекта. В наши дни, когда и Azure, и AWS имеют в основном равные предложения по стоимости и функциям, решения в большей степени принимаются на основе политики и восприятия. Мне нечего принести, когда они говорят: «Прошло X недель / месяцев после официального выпуска, а AWS все еще не готов»

Опять же, как говорит @ VagyokC4 , это не личное противодействие сотрудникам, выполняющим фактическую работу, а скорее

Каждый, кто использует .NET Core 3.1 Lambda, может рассмотреть возможность включения обрезки IL. Скорее всего, вы собираетесь уменьшить размер ваших zip-файлов.
https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfconhibitedSingleExecutable.aspx

.NET core lambda 3.1 построен с использованием RuntimeAPI?
в открытую, на гитхабе?
если нет, то почему бы и нет?

Все, что я хочу ... День святого Валентина - это поддержка лямбда .net core 3.1.

Все, что я хочу ... День святого Валентина - это поддержка лямбда .net core 3.1.

С языка точно не скатывается, но гудит:

Я не хочу много на Рождество , День святого Валентина
Мне нужно только одно
Я не забочусь о подарках
Под деревом AWS
Я просто хочу это для себя
Больше, чем вы могли когда-либо знать
Сделай мое желание сбыться
Все, что я хочу на День святого Валентина, - это поддержка .NET Core 3.1 ...

:ухмылка:

Microsoft включает лицензии Go Live ближе к концу цикла предварительного просмотра, когда они не будут вносить никаких критических изменений. К этому моменту они предлагают производственную поддержку для этого предстоящего выпуска. Я бы порекомендовал подождать, пока они выпустят релиз с лицензией Go Live, а затем начать работу над инструментарием. В .NET Core 3.1 он появился в Preview 3, выпущенном 14 ноября. В этом случае RTM не состоялась даже через 3 недели, 3 декабря, но все же вы будете ближе к развертыванию функций, когда RTM появится, и клиенты начнут строить ожидания.

Только мои 0,02 доллара

Все, что я хочу ... День святого Валентина - это поддержка лямбда .net core 3.1.

С языка точно не скатывается, но гудит:

Я не хочу много на ~ Рождество ~ День святого Валентина
Мне нужно только одно
Я не забочусь о подарках
Под деревом AWS
Я просто хочу это для себя
Больше, чем вы могли когда-либо знать
Сделай мое желание сбыться
Все, что я хочу на День святого Валентина, - это поддержка .NET Core 3.1 ...

😁

+1 :)

какие-либо обновления среды выполнения .NET Core 3.1 для Lambda?

Мы начинаем новый проект и сильно склоняемся к использованию Lamba для большинства бессерверных приложений, но видя, сколько времени требуется, чтобы получить поддержку LTS-версии, заставляет нас переосмыслить, возможно, изменив архитектуру или поставщика.

<Rant>
Расстраивает то, что политика поддержки AWS Lambda Runtime очень строгая в отношении 30-дневного окна, когда такие функции запрашиваются более 30 дней. Затем, по волшебству, однажды AWS развернет эту функцию, и всем остальным придется с трудом переключиться на .NET Core 3.1. Это ставит БОЛЬШИНСТВО организаций в плохое положение, поскольку зачастую на исправление, тестирование и развертывание чего-либо в производственной среде требуется больше месяца. Мне лично эта политика не по зубам. Однажды (из-за нехватки ресурсов и других высших приоритетов) компания, в которой я работал, на этот раз упустила. Только через 3 месяца мы смогли обновить наши Lambdas до .NET Core 2.1. Как только мы попытались развернуть определенную лямбду с помощью CloudFront, произошло что-то плохое (что? Кто знает, потому что журналы CF - мусор), и потребовался откат. За исключением того, что не было среды выполнения, на которую можно было бы откатиться. Таким образом, это LOCKED развертывание. Мы сразу открыли билет. Через 24 часа мы получили наш первый ответ: «удалите весь стек и начните заново». Это совершенно невежественный ответ, учитывая, что он взял бы наши таблицы DynamoDb с помощью операции «удалить». Мы были заблокированы в этом откате более двух с половиной недель. В конце концов у нас появился инженер поддержки, который разбирался в контейнерных технологиях и помог нам откатиться, а затем оставался на связи, пока наша CloudFormation не сработала. Что было нормально, никаких изменений с первой попытки. Вот почему я ненавижу МВ, потому что он слишком темпераментен, чтобы его использовать.
</Rant>

TL; DR; С политикой поддержки AWS Lambda Runtime Support неприятно работать, и это может привести к неприятностям.
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html

@CraigHead извините за ваш разочаровывающий опыт, но чтобы внести ясность, независимо от того, когда .NET Core 3.1 будет выпущен на Lambda, среда выполнения .NET Core 2.1 будет поддерживаться в Lambda как минимум до 21 августа 2021 года в соответствии с циклом поддержки Microsoft. Не нужно будет спешить с преобразованием функций 2.1 в 3.1. Я предполагаю, что ваш предыдущий опыт был с .NET Core 2.0, что было аномалией для Lambda, потому что это была единственная версия, отличная от LTS, которая использовалась для Lambda. Это было сделано только из-за некоторых серьезных проблем с .NET Core 1.0.

Ага, это был переход с .NET Core 2.0 на .NET Core 2.1. Извините за напыщенную речь. Для некоторых из нас 30 дней - это довольно тяжело. Если посмотреть на общую длину, лямбда потенциально может работать без значительного обслуживания и дополнительного контроля качества.

тем временем это происходит на стороне Azure бессерверной
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

Тем временем команда AWS работает над этим. Язвительные комментарии не помогают
их. Они обновят этот выпуск, когда он будет готов.

Вторник, 11 фев 2020, 18:22, Рати Дзидзигури [email protected]
написал:

тем временем это происходит на стороне Azure бессерверной

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

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAAZVJXAAYET4F7PFFOTO3LRCLUETA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS443DFMVREX1XWWWK3TUL52HS443DFMVREX1
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AAAZVJQK3NBVXBZALM4V5KLRCLUETANCNFSM4JU5UTJA
.

Я не собирался делать язвительный комментарий, а хотел указать, что даже MS недавно объявила о доступности GA для 3.1, поэтому я надеюсь, что AWS скоро завершит свою работу по поддержке 3.1.
.

тем временем это происходит на стороне Azure бессерверной
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

Учитывая, что это язык MS, неудивительно, что Azure превзошла AWS в поддержке этого.

Внимательно слежу за этой веткой - с нетерпением жду обновления моих C # Lambdas.

dotnet core 3.1.0 был выпущен 3 декабря 2019 г.
https://dotnet.microsoft.com/download/dotnet-core/3.1

он был доступен в Azure 23 января 2020 г.
https://azure.microsoft.com/en-us/updates/azure-functions-runtime-30-is-now-available/

нам немного не хватает одного дополнительного месяца по сравнению с Azure

Кстати, вся разработка ядра .NET выполняется в открытом доступе на github.
Так что быть «языком MS» не должно иметь большого эффекта.
Или вы предлагаете клиентам AWS, использующим dotnet, лучше использовать Azure: P?

В любом случае, всем, кто слушает AWS:
нас ждут 3.1 на Лямбде, это важно для нас.

Кстати, вся разработка ядра .NET выполняется в открытом доступе на github.
Так что быть «языком MS» не должно иметь большого эффекта.
Или вы предлагаете клиентам AWS, использующим dotnet, лучше использовать Azure: P?

Я имею в виду, что для облачной платформы Microsoft было бы немного неловко не поддерживать новые функции своего собственного языка. Если честно, я немного удивлен, что им потребовалось чуть больше полутора месяцев! Немного больше внутреннего общения, возможно, позволило бы освободить обоих одновременно.

Я думаю, что AWS хорошо справляется со своей поддержкой .Net, особенно с пакетами разработки, которые подключаются к их сервисам, таким как CloudWatch + ILogging и их привязкой к конфигурации параметров SSM. Это нам очень помогло.

Надеюсь вскоре увидеть релиз 3.1 :)

Мне бы очень хотелось, чтобы в Cloudwatch была лучшая конкретная реализация ILogger Cloudwatch. Это было бы лучше интегрировать в ServiceCollection / ServiceProvider при использовании Lambda SDK. Текущая версия, которая предоставляется в контексте запроса, и статический класс LambdaLogger в основном невозможны для модульного тестирования / проверки вывода журнала, а подключение по умолчанию .netcore ConsoleLogProvider приводит к беспорядочным журналам Cloudwatch.

Мне бы очень хотелось, чтобы в Cloudwatch была лучшая конкретная реализация ILogger Cloudwatch.

Вы пробовали https://github.com/aws/aws-logging-dotnet#aspnet -core-logging?

Как вы хотите, чтобы ваши журналы выглядели как @CraigHead?

В прошлом мы использовали Serilog и https://github.com/structured-log/structured-log для вывода хороших журналов консоли, а также журналов на основе JSON, которые были импортированы в Seq. https://datalust.co/, это был лучший способ получить центральные журналы в действительно красивом формате.

@CraigHead Amazon.Lambda.Logging.AspNetCore - это наша реализация для интеграции регистрации Lambda в IServiceCollection. Эта библиотека вам не подходит.

Я бы не рекомендовал пакет AWS.Logger.AspNetCore из ttps: //github.com/aws/aws-logging-dotnet#aspnet -core-logging для Lambda. Эта библиотека использует фоновый поток для отправки журналов в CloudWatch Logs. Использование такого фонового потока не очень хорошо работает с Lambda, которая замораживает вычислительную среду Lambda, как только возвращается обработчик функции, что означает, что у фонового потока может не быть возможности сбросить сообщения из очереди.

Я не знал об этом. Спасибо за совет!
Я имел в виду Amazon.Lambda.Core.LambdaLogger в SDK.
Я обязательно проверю этот пакет ( Amazon.Lambda.Logging.AspNetCore ).

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

@clearwaterstream
В lambda-land AFAIK нет события, которое уведомит вас о том, что текущий экземпляр прекратит обработку или будет прекращен, поэтому ваше предложение все равно оставит события буферизованного журнала не очищенными (потерянными).

Пожалуйста, не используйте эту ветку для других нужд.
Этот поток был создан, чтобы дать некоторую информацию, когда .NET Core 3.1 на AWS Lambda будет доступен.
И чтобы AWS знал, что мы находимся там и ждем.

Будет ли включен инструмент лямбда-тестирования в версию 3.1? https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

Это мое намерение. Работа продолжается в mock-testtool-31 . Большим улучшением в ветке 3.1 является то, что пользовательский код Lambda теперь работает в отдельном AssemblyLoadContext, что должно исправить множество конфликтов версий, которые у пользователей были с текущей версией. Я смотрю на обратный перенос функции AssemblyLoadContext в версию 2.1.

В качестве примечания. У меня есть дебаты о преобразовании простого пользовательского интерфейса в приложение Blazor на стороне сервера. Есть ли у кого-нибудь с большим опытом работы с Blazor какие-либо отзывы о том, хорошая это идея или плохая?

В качестве примечания. У меня есть дебаты о преобразовании простого пользовательского интерфейса в приложение Blazor на стороне сервера. Есть ли у кого-нибудь с большим опытом работы с Blazor какие-либо отзывы о том, хорошая это идея или плохая?

Что-нибудь Blazor на данный момент - хорошая идея, особенно для тех из нас, кто раскачивает DotNet!

"голый UI" - это какое-то другое приложение, не связанное с .NET Core 3.1 Lambdas?
Кстати, меня вообще не волнует блейзер

@petarrepac Это относится к инструменту тестирования AWS .NET Mock Lambda Test Tool, который мы поставили для помощи в отладке лямбда-функций .NET Core 2.1. Вот сообщение для справки https://aws.amazon.com/blogs/developer/debugging-net-core-aws-lambda-functions-using-the-aws-net-mock-lambda-test-tool/

Я занимаюсь обновлением инструмента для .NET Core 3.1.

@normj
ах не поняла спасибо
Интересная мысль, что нам никогда не понадобился такой инструмент

с нашей точки зрения лямбда - это базовый AspNetCore HttpApi, который вы можете вызывать локально и тестировать локально.
единственное отличие - это файл / класс точки входа, длина которого меньше 50 строк кода.
Кроме того, многие вещи можно правильно протестировать только при развертывании на AWS:

• разрешения
• форма полученных событий JSON и контекст
• ...
  Итак, комбинация:
• хорошие модульные / интеграционные тесты, выполняемые локально
• локальное http-тестирование
• легко развернуть для тестирования среды AWS
  может далеко уйти

или мне не хватает очевидного сценария?

@petarrepac Это одно из больших преимуществ использования моста ASP.NET Core в том, что его действительно легко запускать локально. Я согласен, что лучше всего использовать модульное / интеграционное тестирование, но часто возникает необходимость в быстром специальном тестировании логики приложения, и именно для этого подходит этот инструмент.

Спасибо @normj. Что касается Blazor, это могло бы быть приятным дополнением. По крайней мере, для сценария использования нашей команды он, вероятно, не используется.

Мы находимся в пользовательском интерфейсе достаточно долго, чтобы отправить полезную нагрузку, а затем проходим код в VS.

Вы определенно можете создать несколько лямбда-функций из одной базы кода, используя Lambda Bootstrapper и настраиваемую функцию времени выполнения.

У меня есть набор из 16 лямбд, которые развертываются из одного приложения, а не из «монолита».

Это достигается за счет использования переменной среды _handler для выбора метода, используемого во время выполнения, а не жестко заданного однозначного сопоставления, показанного в образце кода сообщения в блоге.

Я думаю об этом как о консольном приложении, которое получает переключатель, который сообщает ему, каким действием «стать» при запуске.

@martincostello

У меня проблемы с этим на основании вашего объяснения. В моем Functions.cs есть около 20 лямбда-функций, связанных с соответствующими определениями в моем serverless.template. Я понимаю, что вы должны передавать переменную среды с каждым определением, чтобы указать, какую функцию вызывать. Большинство этих функций имеют сигнатуру:

общедоступный APIGatewayProxyResponse ThisLambdaFunction (запрос APIGatewayProxyRequest, контекст ILambdaContext)
{

Как добавить поддержку различных сигнатур лямбда-функций, если у меня есть другие функции, которые принимают другие аргументы (кроме APIGatewayProxyRequest) и разные типы возвращаемых значений?

Пожалуйста, не сорвите нить.

@twopointzero Я

Отсутствие встроенной поддержки .NET Core 3.1 в AWS усложняет жизнь. Нам нужно обновить до 3.1, чтобы обновить до последней версии EntityFramewore Core 3.1.2, которая устраняет проблемы, которые мы наблюдаем с пулом соединений в Aurora (PostgresSQL).

@normj Я полностью понимаю, что мы не

@antsaia С уважением, ваш комментарий

Чтобы сам не сорвать эту тему, это мой последний комментарий по этому поводу.

@normj есть ли какой-либо доступный ресурс (блог, форум и т. д.), где мы можем получить информацию о статусе реализации поддержки .net core 3.1?

Я посещаю эту страницу ежедневно в надежде получить какую-либо новую информацию, но очевидно, что информации недостаточно (поскольку она не предназначена для этого использования). Было бы намного проще, если бы у нас было какое-то базовое обновление, чтобы мы могли планировать заранее.

Как и у многих здесь, наши планы по предоставлению функций во многом зависят от того, можем ли мы использовать 3.1 или должны ли мы разрабатывать его с использованием 2.1. В моем случае 3.1 будет обеспечивать поддержку System.Draw, и это сильно повлияет на функцию, над которой я должен работать.

Все, чего я хочу ... День Святого Патрика - это поддержка лямбда-кода .net core 3.1.

@ liam-sage все, что я смог найти, это несколько сообщений на форуме Amazon, в которых говорилось, что он будет готов в первом квартале 2020 года. https://forums.aws.amazon.com/thread.jspa?threadID=313806

@ liam-sage все, что я смог найти, это несколько сообщений на форуме Amazon, в которых говорилось, что он будет готов в первом квартале 2020 года. https://forums.aws.amazon.com/thread.jspa?threadID=313806

Это означает, что он должен выйти в эфир в марте. Я жду.

Привет, я знаю, что это не совсем подходит, но вы можете обновить свои собственные лямбды до dotnetcore 3.1. А пока вы ждете, я бы посоветовал вам создать много лямбда-выражений для написания собственного шаблона dotnetcore. Я сделал это для себя. Я хотел убедиться, что мне не придется тратить часы на шаблонный код. Пример шаблона можно найти здесь .

И Винсент, как мы его разместим? используя настраиваемую среду выполнения?
Чт, 5 марта 2020 г., 19:40 Винсент ван дер Уолт <
[email protected]> написал:

Привет, я знаю, что это не совсем подходит, но вы можете получить свои собственные лямбды
обновлен до dotnetcore 3.1. А пока вы ждете, я бы предложил
если вы создадите много лямбда-выражений для написания собственного шаблона dotnetcore. я сделал
это для меня. Я хотел убедиться, что мне не придется тратить часы на
шаблонный код. Пример шаблона можно найти здесь
https://github.com/vincentvanderwalt/aws-lambda-dotnetcore-3-template .

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AGIDH4OWUT7Y3HR3O5KARBDRF62V3A5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS443VMVREX26PNVWWK3TUL52HS443DFVREX26PNVWWK3TUL52HS443DFVREX26
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AGIDH4PLKFSDLNBX2QVMG63RF62V3ANCNFSM4JU5UTJA
.

Да, он использует настраиваемую среду выполнения.

Вы можете запустить его локально на своем компьютере или развернуть на aws.

F5 для локального и dotnet lambda deploy-serverless для развертывания в aws

В файле readme объясняется, как установить шаблон на локальный компьютер (это шаблон dotnetcore).

Пользовательские среды выполнения - это круто, но я все еще жду полной поддержки AWS для .Net Core 3.1 для лямбда-выражений, чтобы использовать их в производственных средах 😄

Каждый раз, когда я вижу это в своем почтовом ящике, я с нетерпением открываю его, чтобы посмотреть, есть ли у @normj
объявил что-либо только для того, чтобы найти публикацию, которая хотя бы немного не соответствует действительности
тема. Кто-то еще попросил других не перехватывать нить, и это не помогло.
работал. Может ли кто-нибудь заблокировать ветку, пока кто-нибудь не будет готов объявить
выпуск поддержки 3.1?

Пт, 6 марта 2020 г., 7:13 bartoszsiekanski [email protected]
написал:

Пользовательские среды выполнения - это круто, но я все еще жду полной поддержки AWS
для .Net Core 3.1 для лямбда-выражений, чтобы использовать их в производственных средах 😄

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAVUT3SNDR4L2ZL5J4KQYDDRGDSHBA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HSG63JKYY3PNVWWK3TUL52HS4DFMVREPNVWWK3TUL52HSG43LVMVREK3TUL52HS4DFMVREV2
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AAVUT3TBH3NIBMGB54EFCR3RGDSHBANCNFSM4JU5UTJA
.

Пожалуйста, создайте отдельные вопросы для чего-либо, кроме обсуждения поддержки .NET Core 3.1. Могу я закрыть эту проблему, пока у нас не будет новых новостей @normj ?

@ hounddog22030 Я не понимал, что «перехватываю» нить. Я предлагал вместо того, чтобы постоянно спрашивать, готова ли она, что существуют альтернативные подходы, если люди отчаянно пытаются перейти на dotnetcore 3.1. Официальная поддержка, не относящаяся к пользовательской среде выполнения, будет готова, когда она будет готова. Людям просто нужно быть немного терпеливее или искать альтернативный подход.

Если AWS поддерживает параметр --self-contain в команде пакета dotnet lambda, лямбда-функции должны быть исполняемыми независимо от их версии SDK. Правильно? Почему бы не сделать это вместо добавления поддержки для каждого выпуска .NET Core?

Если AWS поддерживает параметр --self-contain в команде пакета dotnet lambda, лямбда-функции должны быть исполняемыми независимо от их версии SDK. Правильно? Почему бы не сделать это вместо добавления поддержки для каждого выпуска .NET Core?

Вы только что описали настраиваемую функцию времени выполнения лямбда

@aussiearef Это действительно хорошо работает, но автономный пакет включает в себя сам .Net Core, который обычно составляет не менее 40 МБ (в архиве) для веб-сайта, оставляя мало места для самого приложения и зависимостей.

При использовании той же версии ядра .NET пользовательская среда выполнения также работает медленнее (холодный запуск), чем собственная среда выполнения. В версии 3.1 добавлено множество улучшений производительности, так что вы можете рассчитывать на тот же уровень производительности между полностью оптимизированными версиями 3.1 и встроенными версиями 2.1. Я надеюсь, что 3.1 native принесет значительные улучшения.

Первый квартал завершится через 4 дня, но похоже, что мы не увидим 3.1 в лямбде.
Я надеюсь, что все члены команды будут в безопасности во время этой пандемии, и надеюсь увидеть этот выпуск во втором квартале.

Не теряйте надежды, что у нас осталось несколько дней! Мы все в значительной степени заняты ожиданием окончательного развертывания и других действий в последнюю минуту. Имейте в виду, что все мы знаем программное обеспечение, и в последний момент могут возникнуть проблемы.

На самом деле я планирую в ближайшее время начать развертывание новых обновлений клиентских инструментов, чтобы убедиться, что все доступно после открытия среды выполнения. Поэтому, если вы видите, что новые обновления пакета NuGet выходят, не предполагайте, что там есть среда выполнения. Подождите, пока не выйдет сообщение в блоге, и я опубликую здесь обновление.

Это фантастические новости. Спасибо @normj

С нетерпением жду публикации в блоге и релиза.

Не теряйте надежды, что у нас осталось несколько дней! Мы все в значительной степени заняты ожиданием окончательного развертывания и других действий в последнюю минуту. Имейте в виду, что все мы знаем программное обеспечение, и в последний момент могут возникнуть проблемы.

На самом деле я планирую в ближайшее время начать развертывание новых обновлений клиентских инструментов, чтобы убедиться, что все доступно после открытия среды выполнения. Поэтому, если вы видите, что новые обновления пакета NuGet выходят, не предполагайте, что там есть среда выполнения. Подождите, пока не выйдет сообщение в блоге, и я опубликую здесь обновление.

Ваше терпение перед лицом отношения в этой ветке впечатляет. Спасибо, что поработали над этим!

@normj с радостью поможет с любым тестированием, которое вы, возможно, захотите провести перед публикацией;)

Осталось еще 2 дня и скрестим пальцы.

И его осталось 13 часов до конца квартала

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

Спасибо всем за терпение. @raRaRa Я предоставляю вам честь закрыть этот выпуск.

Большой

Вт, 31 марта 2020 г., 20:06 Норм Йохансон, [email protected] написал:

И его осталось 13 часов до конца квартала

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

Спасибо всем за терпение. @raRaRa https://github.com/raRaRa
Я оставляю вам честь закрыть этот выпуск.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-606785798 ,
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AGUX3OUR6LN5CERIBTDHXP3RKIWLVANCNFSM4JU5UTJA
.

Спасибо!!!!

И .... Отписываюсь :-)

Спасибо всем причастным !!!

Спасибо!

И его осталось 13 часов до конца квартала

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

Спасибо всем за терпение. @raRaRa Я предоставляю вам честь закрыть этот выпуск.

Хорошая работа!

Это ребенок AWS. Это AWS !!!
Что бы ни случилось, в конце концов они это сделают.

Большое спасибо, команда !!!

Отличные новости и большое спасибо @normj !!! Рискуя показаться глупым и / или жадным, означает ли это по сути и Powershell 7? Просто двойная проверка ...

Отличная работа, @normj и все в AWS! 🥳

Вот ссылка на блог для тех, кто прокручивает вниз
https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

здорово, огромное спасибо за добавление поддержки dotnet core 3.1 !!!

@andyKalman Пока нет в PowerShell 7. Я делаю последние доработки в модуле AWSLambdaPSCore, а затем добавлю в галерею выпущенную версию 2.0.0 AWSLambdaPSCore.

Я ценю быстрый ответ @normj . Я действительно видел # 607 постфактум, так что приятно видеть, что это похоже на быстрое продолжение. Есть ли еще одна проблема, которую нужно отслеживать, чтобы я мог остановить комментарии здесь? :) Спасибо еще раз.

Поздравляю!
И спасибо AWS и .NET Team!
Очень признателен.

Спасибо всем, кто помог в этом! Это огромный релиз, и он показывает, что над ним было вложено много тяжелой работы! Отлично! 🎉🥳

Спасибо !! : clap :: clap :: tada :: tada:

Поздравляю, ребята, с нетерпением жду обновления.

Спасибо!

Отличная работа, хочу обновить эти лямбды.

Отличная работа! Спасибо @normj 👏 👏

Отличная рабочая команда!

Готовы перейти на Lambda-воркеры с подписками dotnet 3.1 Async Streams + AWS AppSync / GraphQL.
Команда AWS, большое спасибо!

OMG, ребята, вы правила! Удивительный! Woohoo! 😄😄😄

БЛАГОДАРНОСТЬ!

@andyKalman Я выпустил версию 2.0.0 модуля AWSLambdaPSCore, который теперь использует PowerShell 7. Я планирую опубликовать сообщение в блоге о поддержке PS7, но он действует так же, как существующая поддержка PowerShell 6, только использует 7.

@andyKalman Я выпустил версию 2.0.0 модуля AWSLambdaPSCore, который теперь использует PowerShell 7. Я планирую опубликовать сообщение в блоге о поддержке PS7, но он действует так же, как существующая поддержка PowerShell 6, только использует 7.

Обновляет ли новая версия AWSLambdaPSCore какие-либо конфигурации в моих существующих функциях Lambda, если я публикую их с новой версией? Как он будет указывать на dotnet3.1 и ps7?

@ tr33squid Да, при развертывании с 2.0.0 будет использоваться .NET Core 3.1 и PS7

Большое спасибо и отличная работа, команда AWS !!

Всем привет,

Я активно работаю над внедрением поддержки .NET Core 3.1 в Lambda. Это займет некоторое время, потому что Microsoft проделала большую работу по созданию среды выполнения. Я работаю над внесением этих изменений, чтобы предоставить вам родную среду выполнения.

Спасибо основной команде AWS-Lambda .NET

Привет,
Я получаю эту ошибку при попытке запустить AWS-Lambda
Не удалось найти совместимую версию фреймворка.
Указанный фреймворк Microsoft.AspNetCore.App версии 3.1.0 не найден.
какие-либо предложения ??

Привет,
Я получаю эту ошибку при попытке запустить AWS-Lambda
Не удалось найти совместимую версию фреймворка.
Указанный фреймворк Microsoft.AspNetCore.App версии 3.1.0 не найден.
какие-либо предложения ??

Вам необходимо установить 3.1.0 SDK.

Я считаю, что Microsoft.AspNetCore.App следует удалить из вашего проекта.
зависимости, которые больше не нужны для Core 3.1.0, мне пришлось удалить его, чтобы
построить и развернуть сервис, который я обновил с версии 2.1.

Пт, 24 апреля 2020 г., в 3:24 Грегори Лайонс [email protected]
написал:

Привет,
Я получаю эту ошибку при попытке запустить AWS-Lambda
Не удалось найти совместимую версию фреймворка.
Указанный фреймворк Microsoft.AspNetCore.App версии 3.1.0 был
не найден.
какие-либо предложения ??

Вам необходимо установить 3.1.0 SDK.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-618850277 ,
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA
.

-
Лучший,
Георгий

Джордж Таскос
Старший архитектор решений

WeAre8
230 Park Avenue, 3 эт. Запад
Нью-Йорк, NY 10169
(917) 717-9067
weare8.com

Частный вход,
71 Vanderbilt Ave
3-й этаж

Я считаю, что Microsoft.AspNetCore.App следует удалить из зависимостей вашего проекта, он больше не нужен для Core 3.1.0, мне пришлось удалить его, чтобы создать и развернуть службу, которую я обновил с версии 2.1.
…
В пятницу, 24 апреля 2020 г., в 3:24 Gregory Lyons @ . * > писал (а): Привет, я получаю эту ошибку при попытке запустить AWS-Lambda. Не удалось найти совместимую версию фреймворка. Указанный фреймворк Microsoft.AspNetCore.App версии 3.1.0 не найден. какие-либо предложения ?? Вам необходимо установить 3.1.0 SDK. - Вы получаете это, потому что подписаны на эту беседу. Ответьте на это письмо напрямую, просмотрите его на GitHub < # 554 (comment) > или откажитесь от подписки https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA .
- Бест, Джордж Джордж Таскос, старший архитектор решений WeAre8 230 Park Avenue, 3-й эт. West New York, NY 10169 (917) 717-9067 weare8.com Частный вход, 71 Vanderbilt Ave, 3-й этаж

Спасибо за ваш ответ,
На самом деле эта ошибка возникла из-за моей глупой ошибки. Я забыл удалить runtime: dotnetcore2.1 в моем serverless.yml. Теперь проблема решена.

Кто-нибудь делает какие-либо обновленные тесты / сравнения по этому поводу? Все, что я могу найти, - это старые с настраиваемой средой выполнения ..

Кто-нибудь делает какие-либо обновленные тесты / сравнения по этому поводу? Все, что я могу найти, - это старые с настраиваемой средой выполнения ..

Вот хороший.
https://medium.com/@zaccharles/a -close-look-at-net-core-3-1-on-aws-lambda-9ccec4dd96be

Также мой личный опыт обновления сложной лямбды 2.1 до 3.1 при размере лямбды 512 МБ показал почти такую ​​же производительность (холодный и теплый старт). И в 2.1, и в лямбда-выражениях 3.1 используется уровень лямбда, оптимизированная публикация, newtonsoft (возможно улучшение производительности с помощью Microsoft json в версии 3.1), отключение многоуровневой компиляции и RTR для 3.1.

Судя по моим показателям, производительность в среде выполнения dotnet 3.1 немного увеличивается, но производительность снижается при инициализации Amazon Linux 2 и dotnet 3.1. (2.1 использует Amazon Linux 1.) Мытье прибыли.