将ASP.NET App部署到Azure Web App时出现HTTP 500.79错误/System.UriFormatException [英] HTTP 500.79 Error / System.UriFormatException when deploying ASP.NET App to Azure Web App

查看:103
本文介绍了将ASP.NET App部署到Azure Web App时出现HTTP 500.79错误/System.UriFormatException的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试为ASP.NET MVC应用程序设置暂存环境,并希望将其作为Azure Web应用程序来实现,但是目前我真的停留在HTTP 500上.

I am attempting to set up a Staging Environment for an ASP.NET MVC Application, and want to do that as an Azure Web App, but I am really stuck on an HTTP 500 at this point.

我得到的错误是:

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

使用诊断日志,我能够获得堆栈跟踪:

Using diagnostics logs I was able to get a 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的:

I've used any other diagnostics tool that I was able to find on Azure, but was not able to figure out a lot more, except one faint hint: Using the Failed Request Tracing feature I noticed that those traces state that the requests were made to very odd and obviously wrong URL's:

根据请求跟踪的URL:https://Skillmanagementtest:80

URL according to Request Trace: https://Skillmanagementtest:80

实际请求的网址:https://skillmanagementtest.azurewebsites.net

截屏:失败的请求跟踪

我绝对不知道此URL或端口来自何处;我从未在任何地方指定端口80(无论如何,它的HTTPS是错误的). "Skillmanagementtest"是我给Azure Web App命名的名称,我认为我没有在其他任何地方使用过它.正确设置了主页URL和用于身份验证的答复URL(使用AAD作为身份验证提供程序).我的假设是,导致UriFormatException的是乱码的URL,但是我不知道URL的来源...

I have absolute no clue where either this URL or the port comes from; I have never specified port 80 anywhere (which is wrong anyway as its HTTPS). "Skillmanagementtest" is the name I have given the Azure Web App, and I don't think that I have used it anywhere else. The Home Page URL and the Reply URL for Authentication (using AAD as Authentication Provider) is set correctly. My assumption is, that it is this gibberish URL that causes the UriFormatException, but I've got no clue where the URL is coming from...

也就是说,该应用程序似乎正常启动(还包括诸如日志记录框架之类的文件,这些文件将它们的文件放置在启动工作中),并且启动该应用程序也不会在诊断日志中放置任何错误,但是,每当发出请求时,发生上述错误.

That said, the application seems to start up properly (also things like logging frameworks placing their files on startup works), and starting it up also does not place any errors into the diagnostic logs, but whenever a request is made, the above error occurs.

在本地和生产环境中(使用经典" VM,而不是Azure Web App)运行Web App都没有问题,但是我无法发现它们与Azure Web App之间的配置存在任何差异(当然,不同的文件路径和数据库连接).还给出了命名为Azure中间件的Stack Trace的提示,该问题源于作为Azure Web App运行的应用程序,并且由于我几乎唯一拥有的杠杆作用,因此应该存在一些配置错误...

Locally and in production (using a "classical" VM, not an Azure Web App) the Web App runs without problem, but I was not able to spot any difference in configuration between those and the Azure Web App (except of course the different file paths and DB connections). Also given the Stack Trace naming an Azure Middleware suggests that the problem originates from the app being run as Azure Web App, and as the only leverage I pretty much have there it oughta be some configuration error...

作为设置暂存环境的一部分,我旨在实现尽可能多的自动化.因此,我还设置了CI/CD响应.使用Azure DevOps构建和发布管道.这似乎一切正常.在配置方面,我在web.config上使用XML转换. web.Staging.config文件.转换都正确应用了.

As a part of setting up the Staging Environment I aim towards having as much as possible automated. Thus I have also set up a CI/CD resp. a Build and a Release Pipeline using Azure DevOps. This seems to work all fine. Configuration-wise I use XML Transformations on the web.config resp. web.Staging.config file. The transformations are all applied correctly.

-

对于可能出什么问题的任何想法,我将不胜感激,因为我自己几乎没有什么可以尝试的东西了(整整三天,我正在努力让它起作用...)

For any ideas on what may be wrong I would be immensly grateful, as I myself have pretty much run out of things to try (third full day I am trying to get this to work...)

〜Finrod

推荐答案

解决方案":我已修复此错误,并分别用另一个错误替换了该错误.错误的URL是App Service的身份验证/授权"部分中的发行者ID";我填写了承租人(即"xxxxx.onmicrosoft.com"),而不是按此处说明的发行人URL: https://docs.microsoft.com/zh-CN/azure/app-service/configure-authentication-provider-aad .但是,当我尝试向应用程序发出请求时,我得到了403.对此我将提出一个新的问题,因为我再也不知道该怎么做,但是也许有人也在这里遇到了这个问题.

"Solution": I have fixed this error, respectively replaced it with a different one. The URL which was erronous was the "Issuer ID" in the "Authenticatio / Authorization" section of the App Service; I filled in the tenant (i.e. "xxxxx.onmicrosoft.com") instead of the issuer URL as explained here: https://docs.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad. However, I get a 403 now, when trying to make requests to the app. Will make a new question for this as I once more have no clue what to do, but maybe someone encounters this problem here as well.

这篇关于将ASP.NET App部署到Azure Web App时出现HTTP 500.79错误/System.UriFormatException的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆