Приложение ASP.NET Core 2.1, предварительная версия 2, не работает в службе приложений Azure
Я запускаю свое приложение ASP.NET Core 2.1 Preview-1 в Azure с тех пор, как этот выпуск стал доступен. Я установил расширения среды выполнения ASP.NET Core через портал, и он работает нормально.
Теперь, когда Microsoft выпустила ASP.NET Core 2.1 Preview-2, я установил обновление до SDK. Обновил свои пакеты Nuget, так что у меня есть предварительная версия 2 всего. См. Мой файл csproj ниже:
Я также удалил расширения среды выполнения ASP.NET Core из службы приложений Azure для своего приложения, которое показывало 2.1 Preview-1. Вместо этого установили время выполнения ASP.NET Core 2.1 для x86 и x64 отдельно - см. Ниже:
Скомпилировал приложение и опубликовал его в моей службе приложений Azure, но я получаю ошибки. Сначала я получил ошибку 502,5. Теперь я получаю:
The specified CGI application encountered an error and the server terminated the process.
Что мне здесь не хватает?
ОБНОВИТЬ:
Как подсказал ответ, я установил свою цель на x86 (чтобы не рисковать) - см. Ниже:
Я удалил расширение и отдельные времена выполнения x86 и x64 и установил только x86 с поддержкой ASP.NET Core 2.1 preview-2 - см. Ниже:
Я перезапускал приложение несколько раз, но все равно получаю 502,5.
Затем я попытался выполнить самостоятельное развертывание через командную строку CLI, введя следующую команду:
dotnet publish -c Release -r win10-x64
И я получаю следующую ошибку:
C:\Program Files\dotnet\sdk\2.1.300-preview2-008530\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(125,5): error : The RuntimeIdentifier platform 'win10-x64' and the PlatformTarget 'x86' must be compatible.
Означает ли это, что у меня установлена версия SDK для x86 и я должен настроить таргетинг на x86?
У меня не было половины тех проблем, которые я испытываю сейчас, переходя с ASP.NET Core 2.0 на 2.1 !!!!
ОБНОВЛЕНИЕ 2:
Просто запустил dotnet --info в консоли Kudu. Если я правильно это читаю, значит, у меня неправильная среда выполнения.
Обновление 3:
Думаю, этот снимок экрана подтверждает то, что я говорил.
Обновление 4:
Я установил x86 версию ASP.NET Core 2.1 Runtime - см. Ниже:
Когда я запускаю dotnet --info в консоли Kudu, я получаю следующее, что меня смущает. Я все еще не вижу ту версию, которую ожидал увидеть:
И когда я нажимаю URL-адрес, я все еще получаю 502.5 и такое же сообщение в консоли Kudu, когда я запускаю dotnet MyApp.dll, говоря мне, что правильная версия среды выполнения не найдена.
Как мне получить там правильную версию? Я думал, что установка через портал сделает это.
Нет интересного сообщения. Я выполнил инструкции и создал пустой файл журнала. Я снова нажимаю URL-адрес своего приложения, и он создает второй файл журнала. Внутри файла журнала все, что я вижу, это: Среда хостинга: Производство Корневой путь к содержимому: D: \ home \ site \ wwwroot Теперь слушаем: 127.0.0.1:32458 Приложение запущено. Нажмите Ctrl + C, чтобы выключить.
Я получаю сообщение об ошибке 502.5 или в исходном сообщении. Кажется, что между этими двумя ошибками происходит переход туда и обратно. Кроме того, что довольно интересно, я получаю сообщение об ошибке целую вечность. Я получаю сообщение об ошибке через 45-60 секунд.
Я нахожусь в одной лодке с Сэмом, симптомы точно такие же. 502.5 или ошибка CGI. Запуск из консоли Kudu работает правильно.
Когда вы устанавливаете .NET через расширение сайта, расширение сайта изменяет ПУТЬ вашего сайта, помещая себя в начало. Каждое расширение сайта является автономным. Если вы установите оба, то только одно «выиграет», и он ничего не будет знать о другом расширении.
Когда вы публикуете автономную версию, я предполагаю, что причина ее неудачи в том, что вы публикуете для x64, а строите для x86. Если вы собираетесь публиковать для x64, вам также следует установить это в качестве целевой платформы в VS.
@Glenn В настоящее время у меня есть только один - ASP.NET Core Extensions 2.1.0-preview2-final, который, кажется, устанавливается автоматически каждый раз, когда я публикую свое приложение. Несмотря на то, что у меня только одно расширение, приложение все еще не работает в Azure.
Я бы хотел увидеть результат запуска dotnet myapp.dll в консоли Kudu, если вы публикуете его в обычном режиме (без RID) с установленным только одним расширением времени выполнения. Я понимаю, что вы это сделали и получили 502.5, но я не знаю, в чем была ошибка. Также запустите dotnet --info на консоли Kudu, чтобы убедиться, что вы получаете версию .NET из расширения сайта.
@Glenn См. Обновление 2, которое я только что опубликовал в исходном сообщении.
Верно. ASP.NET Core Extensions только ведет журнал. У вас установлено расширение, в названии которого указано время выполнения? Если вы не установите один из них, то x86, если вы все еще нацеливаетесь на него в VS, и попробуйте dotnet --info еще раз.
@Glenn См. Обновление 4.
Вы перезагружали перед запуском dotnet --info? Ваш сайт должен остановиться и запуститься снова, чтобы произошло изменение PATH. Поскольку он работает путем преобразования ваших файлов конфигурации IIS и происходит только во время запуска. Я заметил здесь некоторую странность, где вы говорите сайту о перезапуске, и он говорит, что он перезапустился, но затем фактический перезапуск некоторое время не происходит. Такие вещи. Не уверен, что вы попадаете во что-то подобное. Но какую бы версию dotnet --info ни показывал, ваше приложение будет использовать.
Да. Я просто сделал это еще раз, чтобы убедиться, и я все еще получаю те же номера версий. Я думаю, что правильная версия для превью-2 - 2.1.300. Я получаю 2.1.101
Позвольте нам продолжить обсуждение в чате.
Я никогда не развертывал приложения на zip. Мне удалось создать автономное развертывание в папке publish. Могу ли я просто заархивировать его и перейти к «Zip Push Deploy» в «Tools»?
Это уже исправлено? Я пробовал все в этом вопросе, и мне не повезло. В настоящее время ожидает обратного звонка от Microsoft для устранения неполадок.
Я не смог решить эту проблему. Сегодня я загрузил свой код в новое приложение Azure - используя уровень бесплатного пользования - и мое приложение заработало. Мне пришлось установить его на x64 и убедиться, что у меня установлена только x64-версия SDK. Я делал то же самое в своем другом приложении, которое находится на платном уровне, и ничего из того, что я сделал, не сработало. Интересно, есть ли проблема с Azure, когда некоторые вещи не удаляются - возможно, старая версия SDK.
У меня была такая же мысль, но моя мысль немного сложнее, потому что я также использую среду службы приложений. Когда я пытаюсь запустить dotnet AppName.dll в консоли KUDU, он говорит, что проблема с моими основными данными. До сих пор ничего не слышал от Microsoft, даже с лицензией EA и билетом поддержки «Critical» в :(
Я потерял это из виду и никогда не вернусь, чтобы закончить помогать тебе. Но сейчас это не имеет значения, потому что RC отключен и установлен в Службе приложений Azure без расширения сайта. Таким образом, вы можете удалить их все и получить RC. Верно?
Нет, все еще крайне непоследовательно. У меня он работал около 10 минут, затем он остановился.
@Sam вы используете среду службы приложений или виртуальную сеть в своей конфигурации Azure?
@LouisLewis Теперь, когда выпущена полная версия ASP.NET Core 2.1, все работает так, как должно.
Ответы 7
Шаги, которые я предпринял, чтобы это заработало:
- Удалите расширение времени выполнения ASP.NET Core 2.1-preview1.
- Проверьте настройки приложения, чтобы узнать, работаете ли вы в 32-разрядной или 64-разрядной версии.
- Установите только соответствующую (32- или 64-разрядную) среду выполнения ASP.NET Core 2.1.
- Перезапустите веб-приложение.
Перезапуск важен - перед перезапуском инструменты .NET Core были неправильной версии, и я также получил бы ошибку 502,5.
Поскольку вы установили как 32-, так и 64-разрядную среду выполнения, я бы попытался удалить ту, которая не нужна вашему приложению, и перезапустить веб-приложение.
Ничего из того, что я сделал, не работает. Смотрите мое обновление в исходном посте.
Вы перезапустили веб-приложение? Я получил тот же результат, что и вы, от dotnet --info перед перезапуском.
Неважно, я вижу в комментариях выше, что вы уже перезапустили
У меня была аналогичная проблема с версией 2.1.2. Перезапуск помог мне. Благодарность!
Попробуйте добавить файл global.json в папку вашего проекта со следующим содержимым:
{
"sdk": {
"version": "2.1.300-preview2-008530"
}
}
После этого перезапустите приложение на всякий случай.
Это тоже не помогло! Кроме того, я заметил, что каждый раз, когда я публикую свое приложение в Azure через Visual Studio, оно автоматически добавляет ASP.NET Core Extensions и выглядит так, как будто это версия 2.1.0-preview2-final.
Я публикую с помощью профиля публикации (загруженного из Azure). Я вручную добавил расширение ASP.NET Core 2.1 (x86) Runtime. После добавления файла global.json он заработал. До этого я мог запускать его только из консоли Kudu.
Просто совсем не работает! Провел довольно много времени с Гленом из Microsoft в чате. Ничего из того, что мы пробовали, никогда не сработало. Я даже опубликовал его на новом сайте в Azure, убедившись, что он использует правильную структуру, но по-прежнему просто не работает. Я одновременно разочарован и потерял дар речи!
Установите его на использование любого процессора. Потом попробовал x86. Потом попробовал x64. Добавлен global.json. Скачал профиль публикации. Перезапускался бесчисленное количество раз, и ничего не работало!
Через пару минут я снова получаю ошибку CGI, даже с файлом global.json :( Итак, я вернулся к аналогичной ситуации. Никаких журналов, ничего в App Insights.
Я тоже застрял. Ничего из того, что я делаю, не работает. Что еще хуже, если я настрою свой профиль публикации на целевую среду выполнения x64, я не смогу опубликовать. Я пробовал автономный режим, FTP и т. д. Вот и другая моя проблема: stackoverflow.com/questions/49819536/… Я просто не могу заставить эту штуку работать !!!
Вот единственное, что, кажется, сработало у меня.
Я выполнил автономное развертывание, используя
dotnet publish --self-contained -r win10-x64 -c Release
Затем мне пришлось выполнить развертывание вручную - в моем случае с использованием FTP.
Мне бы очень хотелось, чтобы эта проблема была решена, но если она не будет решена при следующем развертывании, я выполню развертывание zip-архива. Поскольку у моего приложения есть интерфейс ReactJs, нужно было развернуть тысячи файлов, и FTP не доставлял большого удовольствия!
Поскольку этот подход не зависит от того, что установлено или не установлено в службе приложений Azure, это гораздо более простое решение.
Я все еще хочу иметь возможность просто щелкнуть Опубликовать в Visual Studio!
ОБНОВИТЬ:
Я только что выполнил развертывание zip-архива, но все еще получаю ошибки, которые я получал раньше, хотя развертывание zip-архива прошло успешно. Итак, что-то все еще не так!
Мой проект работает над asp.net core 2.1 Preview 2 в Azure. Я сделал следующие шаги;
- Удалено старое расширение ядра asp.net из расширения службы приложений Azure.
- С помощью кудуса удалил все файлы в папке wwwroot сайта.
Установлено расширение основного сайта asp.net из Azure, как показано на рисунке ниже, и перезапущена служба приложения.
- Перед развертыванием в Azure используется параметр конфигурации публикации, как показано на рисунке ниже.
Вот и все.
Нам удалось опубликовать веб-приложение ASP.NET Core 2.1 RC1 в службе приложений Azure с использованием «автономного» режима развертывания.
Целевая платформа: любой процессор
Вот ссылки на пакеты из нашего .csproj:
<PackageReference Include = "Microsoft.AspNetCore.App" />
<PackageReference Include = "Microsoft.VisualStudio.Web.CodeGeneration.Design" Version = "2.1.0-rc1-final" PrivateAssets = "All" />
<PackageReference Include = "Microsoft.AspNetCore.AzureAppServicesIntegration" Version = "2.1.0-rc1-final" />
У меня были проблемы с 2.2 и сервером сборки kudu. "dotnet add package Microsoft.AspNetCore.AzureAppServicesIntegration" исправил это
У меня была проблема со сложным веб-сайтом, поэтому я создал простой, используя только файл приложения, установленный в той же версии:
<ItemGroup>
<PackageReference Include = "Microsoft.AspNetCore.App" Version = "2.1.3" />
</ItemGroup>
а затем, взятый из примера Тима Дикманна, я ничего не сделал, кроме изменения Режим развертывания в конфигурации публикации Azure Настройки на Автономный - и это сработало.
Любые интересные сообщения об ошибках с использованием эта техника?