HTTP 500.79 Ошибка / System.UriFormatException при развертывании приложения ASP.NET в Azure Web App - PullRequest
Новая
       69

HTTP 500.79 Ошибка / System.UriFormatException при развертывании приложения ASP.NET в Azure Web App

0 голосов
/ 14 января 2019

Я пытаюсь настроить промежуточную среду для приложения ASP.NET MVC и хочу сделать это как веб-приложение Azure, но на этом этапе я действительно застрял на HTTP 500.

Я получаю ошибку: 

500.79: The request failed because of an unhandled exception in the Easy Auth module.

Используя журналы диагностики, я смог получить Stack Trace: 

2019-01-14T13:07:22  PID[14448] Critical    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.UriFormatException: Invalid URI: The format of the URI could not be determined.
   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
   at System.Uri..ctor(String uriString, UriKind uriKind)
   at Microsoft.Azure.AppService.Middleware.ModuleConfig.set_OpenIdIssuer(String value)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, Object[] index)
   at Microsoft.Azure.AppService.Middleware.MiddlewareConfig.TryLoadConfig(Type type, HttpContextBase context)
   at Microsoft.Azure.AppService.Middleware.ModuleConfig.EnsureConfigLoaded(HttpContextBase context)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at Microsoft.Azure.AppService.Middleware.ModuleManager.LoadModuleConfig(HttpContextBase context)
   at Microsoft.Azure.AppService.Middleware.ModuleManager.LoadAllModulesAndGetEnabledModules(HttpContextBase context)
   at Microsoft.Azure.AppService.Middleware.HttpModuleDispatcher.EnsureInitialized(HttpContextBase context)
   at Microsoft.Azure.AppService.Middleware.HttpModuleDispatcher.<DispatchAsync>d__11.MoveNext()

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

URL в соответствии с трассировкой запроса: https://Skillmanagementtest:80

Фактически запрашиваемый URL: https://skillmanagementtest.azurewebsites.net

Снимок экрана: Трассировка неудачного запроса

Я абсолютно не знаю, откуда взялся этот URL или порт; Я никогда нигде не указывал порт 80 (который в любом случае неверен как HTTPS). Skillmanagementtest - это имя, которое я дал веб-приложению Azure, и я не думаю, что я использовал его где-либо еще. URL-адрес домашней страницы и URL-адрес ответа для проверки подлинности (с использованием AAD в качестве поставщика проверки подлинности) установлены правильно. Я предполагаю, что именно этот бессмысленный URL-адрес вызывает исключение UriFormatException, но я понятия не имею, откуда этот URL-адрес ...

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

Локально и в производственном режиме (с использованием «классической» виртуальной машины, а не веб-приложения Azure) веб-приложение работает без проблем, но я не смог обнаружить никаких различий в конфигурации между ними и веб-приложением Azure (за исключением, конечно, разные пути к файлам и соединения с БД). Кроме того, с учетом наименования Stack Trace промежуточное ПО Azure позволяет предположить, что проблема возникает из-за приложения, запускаемого как Azure Web App, и в качестве единственного рычага, который у меня есть, это может быть ошибка конфигурации ...

В рамках настройки рабочей среды я стремлюсь максимально автоматизировать работу. Таким образом, я также установил CI / CD соответственно. конвейер сборки и выпуска с использованием DevOps Azure. Кажется, все работает нормально. Что касается конфигурации, я использую преобразования XML в web.config соответственно. Файл web.Staging.config. Все преобразования применяются правильно.

-

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

~ Финрод

1 Ответ

0 голосов
/ 15 января 2019

«Решение»: я исправил эту ошибку, соответственно заменил ее на другую. Ошибочным URL-адресом был «Идентификатор эмитента» в разделе «Аутентификация / авторизация» службы приложений; Я заполнил арендатора (то есть "xxxxx.onmicrosoft.com") вместо URL-адреса эмитента, как описано здесь: https://docs.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad. Однако я получаю 403 сейчас, когда пытаюсь сделать запросы к приложению. Я задам новый вопрос, потому что я еще не знаю, что делать, но, возможно, кто-то также сталкивается с этой проблемой здесь.

...