Зазначений фреймворк "Microsoft.AspNetCore.App", версія "3.1.0" не знайдено для Linux Azure WebApp

Проблема

Після оновлення .Net Core 2.2 Linux Web App до .Net Core 3.1 в Azure програма не працює із Specified framework 'Microsoft.AspNetCore.App', version '3.1.0' was not foundпомилкою. Я навіть пішов далеко, щоб створити новий веб-додаток Linux з .Net Core 3.1, і після того, як командна команда bash все ще виводить dotnet --list-runtimesяк 2.2.7.

Деталі

Веб-сайт вниз

Logstream

додаток для звітування не працює, оскільки він не може знайти .net core 3.1.

Створено новий веб-додаток .net core

3.1 linux webapp у North Central, та сама проблема

Переконався, що він працює в Північній Центральній частині США

Згідно з https://aspnetcoreon.azurewebsites.net/ , повинна мати повну підтримку .netCore 3.1

Все-таки .net core 2.2.7

opt/dotnet/runtimes перелічує 3, 3.0 та 3.0.0, але немає 3.1 "

Змінні середовища

Мої змінні середовища в списку Azure FRAMEWORK_VERSION = ltsзамість 3.1

Видавництво

Про це було опубліковано в блакитному конвеєрі, який використовує завдання Azure AppService Deploy. 3.1 не було тут, тому я вибравLTS

Оновлення 1

Здається, винуватець 3,1 відсутній у стеку фреймворків у завданнях веб-додатків / веб-служб Azure Devops.

Щоразу, коли я публікую з CI, рамки веб-додатків оновлюються до того, що вибрано в цьому спадному меню. Якщо я вручну зміню фреймворк на 3.1 у веб-додатку Azure, з’явиться сайт. Але потім при наступному опублікуванні воно знижується, оскільки повертає рамки до налаштувань ci.

Нове питання

Як я можу змусити конвеєр Azure Devops Release опублікувати завдання .net core 3.1?

Оновлення 2

Пов’язане повідомлення на форумі Azure Devops

В даний час проводиться розслідування станом на 23.02.2020 року

.Net Core 3.1 розгорнути конвеєр до служби застосунків Linux

Запропоновані обхідні шляхи

Використовуйте YML для випуску конвеєра та вручну змініть версію з 3.0на 3.1, відзначену відповіддю та цим потоком
Оновлення від framework dependentверсії до а self contained. Довідково
Перехід до .NetCore 3.0

— w00ngy
джерело

Замість використання LTS, будь ласка, спробуйте скористатись останнім (не рекомендується, але спробуйте, все одно, побачите, працює він чи ні)

— Manish

Я це зробив, і це не спрацювало. Але CI, здається, проблема. Кожен раз, коли я публікую у програмі CI, вона змінює рамки веб-програми на те, що вибрано в CI. Якщо я перейду до служби додатків після публікації CI і вручну змінять стек виконання на 3.1, сайт з’являється до наступної публікації.

— w00ngy

НЕ публікуйте зображення коду, даних, повідомлень про помилки тощо - скопіюйте або введіть текст у запитання. Як спитати

— Роб

Відповіді:

Я зіткнувся з тією ж ситуацією, використовуючи надану вами інформацію, що мені вдалося виправити проблему, встановивши значення вручну у файлі .yml Devops Pipelines Build. Здається, що вони просто не вистачають значення з спадного сценарію RunTime Stack. Якщо ви вручну оновлюєте .yml файли процесів збирання, як показано тут:

Це дозволить вибрати правильну рамкову версію. Сподіваємось, це вирішить вашу проблему з розгортанням конвеєра Azure Devops CI.

— Таран Бекхуїс
джерело

Мені було цікаво, чи це вирішить це. Я спробую дати йому зняти. Можливо, мені доведеться трохи попрацювати, щоб перетворити весь свій випуск у yml, тому я ще не пробував цього. Я дам вам знати результати! Вдячний за відповідь !!

— w00ngy

Здається, можна вводити рядок DOTNETCORE | 3.1 прямо у поле Ruckime Stack (і це вирішує проблему) - тому не потрібно перетворювати конвеєр випуску в yaml!

— rdavisau

Я збирався сказати те саме, що і @rdavisau - найпростіше виправити те, щоб перезаписати версію 3.1 в поле Ruckime Stack і, схоже, прийняти значення.

— Чи буде Appleby

— Роб

rdavisau - це врятувало б мені багато часу! Лол.

— w00ngy

DOTNETCORE|3.1Простішим рішенням є введення у спад девайсів Ruckime Stack. (Дякую rdavisau!)

— w00ngy
джерело