"HTTP Error 502.5 - Process Failure" asp.net core error in Azure

ardacetinkaya commented 8 years ago

Hi; I just deployed my asp.net core app to azure which I developed in mac os x. It is successfully build and run on my local environment.

But when I browse the app on Azure site, I got the following error.

screen shot 2016-08-17 at 3 58 31 pm

I checked the link in error https://docs.asp.net/en/latest/publishing/iis.html#common-errors for some info but could not link with my issue.

Also when I check Azure logs, in Application Logs, I have

HTTP Error 502.5 - Bad Gateway The specified CGI application encountered an error and the server terminated the process. Most likely causes: The CGI application did not return a valid set of HTTP errors.A server acting as a proxy or gateway was unable to process the request due to an error in a parent gateway.

Also some additional info in Application Logs

Requested URL--http://maping:80/ (this line seemed interesting to me) Physical Path--D:\home\site\wwwroot

My web.config is like below;

<?xml version="1.0"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/>
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
  </system.webServer>
</configuration>

And finally my project.json file;

`
{
  "buildOptions": {
    "emitEntryPoint": true,
    "preserveCompilationContext": true
  },
  "dependencies": {
    "Microsoft.NETCore.App": {
      "version": "1.0.0",
      "type": "platform"
    },
    "Microsoft.AspNetCore.Mvc": "1.0.0",
    "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
    "Microsoft.AspNetCore.Server.Kestrel": "1.0.0",
    "Microsoft.Extensions.Configuration.EnvironmentVariables": "1.0.0",
    "Microsoft.Extensions.Configuration.FileExtensions": "1.0.0",
    "Microsoft.Extensions.Configuration.Json": "1.0.0",
    "Microsoft.Extensions.Logging": "1.0.0",
    "Microsoft.Extensions.Logging.Console": "1.0.0",
    "Microsoft.Extensions.Logging.Debug": "1.0.0",
    "Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0"
  },
  "frameworks": {
    "netcoreapp1.0": {}
  },
  "publishOptions": {
    "include": [
      "wwwroot",
      "Views",
      "appsettings.json",
      "web.config"
    ]
  },
}`

Any idea?

I have also below properties for project.json

 "tools": {
    "Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final"
  },
  "scripts": {
    "postpublish": "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%"
  }

odinnix commented 7 years ago

@ZombiesWithCoffee Post your project.json if you want, I can diff it with mine see if anything sticks out.

ZombiesWithCoffee commented 7 years ago

All I am getting at this time is the terribly generic error

   The specified CGI application encountered an error and the server terminated the process.

I believe that this problem is related to the issue, that publishing doesn't show the "Entity Framework Migrations" option. Thanks for the offer to help though!

https://forums.asp.net/t/2111466.aspx?Publishing+doesn+t+show+the+Entity+Framework+Migrations+

http://stackoverflow.com/questions/41004824/asp-net-core-project-publish-doesnt-show-the-database-migrations-option

odinnix commented 7 years ago

That error just means Kestrel has crashed (or timed out. I've seen it on super long requests). You might have to dig into the stdout and Azure logging but there should be another error somewhere.

Unfortunately we use EF6 and an adapter and do all migrations through SQL so I can't help there :( Best of luck.

asadsahi commented 7 years ago

@dcarl1 @ZombiesWithCoffee , thanks for pointing out enabling the errors. My issue was a runtime error, which wasn't happening during dev or even in production build locally. Only when I was deploying to azure. Here is the code:

 services.AddDbContext<ApplicationDbContext>(options =>
            {
                string useSqLite = Configuration["Data:useSqLite"];
                if (useSqLite.ToLower() == "true")
                {
                    options.UseSqlite(Configuration["Data:SqlLiteConnectionString"]);
                }
                else
                {
                    options.UseSqlServer(Configuration["Data:SqlServerConnectionString"]);
                }

            });

So, I added UseSqlServer in options, but the "Microsoft.EntityFrameworkCore.SqlServer": "1.1.0",package wasn't added. So this was causing a runtime error, and only on Azure. Neither running locally nor a production build was causing any issues.

moozzyk commented 7 years ago

See: https://github.com/aspnet/Home/issues/1842#issuecomment-265951372

ricklove commented 7 years ago

Wow, this killed my productivity for a whole day. This thread did not help me specifically, but it was the best one that I could find in searching. I wanted to leave my findings here in case others find it and need a different option:

I created a new project with VS and it published fine. So, I started copying files over to see if I could introduce the error. Nope, the new project published just fine to Azure with the same startup, project.json, web.config and all the content files.

Finally, I got WinMerge and found a few differences:

SolutionFiles/global.json had a different SDK version, so I changed that to match new newer version
PublishProfiles was different, so I deleted all my old publish profiles and started over

That fixed it!

ZombiesWithCoffee commented 7 years ago

I did the same thing @ricklove . I finally had to break down for the 6th time and recreate the project from scratch to finally get it to work again. So it's definitely not a code issue.

I wish my problem was a simple as the global.json file. Mine are the same.

ricklove commented 7 years ago

Definitely a very frustrating experience after having no problems publishing with this project and then all of a sudden it blew up. It had been about a month since I had published with this project (but never had a problem with it) and I may have updated other projects and maybe the VS tooling or something.

The project was originally a RC2 project and is now at 1.0.1. I was just happy it worked and didn't bother trying to upgrade to the latest.

nilavghosh commented 7 years ago

I commented the sdk version from global.json in the solution and the deployment to azure started working fine.

{
  "projects": [ "src", "test" ]
  //,
  //"sdk": {
  //  "version": "1.0.0-preview2-003131"
  //}
}

damccull commented 7 years ago

Just an FYI for anyone finding this error. My problem causing it was because I use Kestrel with HTTPS in my startup and provide it a development key. That key doesn't exist on azure and never will, so it throws an exception. I solved it by the following technique:

    public class Program {
        public static void Main(string[] args) {
            var host = new WebHostBuilder()
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseStartup<Startup>();

            if (Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") == "Development") {

                host.UseKestrel(options => {
                    var pfxFile = "kestrel-dev-cert.pfx";
                    options.UseHttps(pfxFile, "password");
                })
                .UseUrls("https://localhost:44348");
            } else {
                host.UseKestrel();
            }

            var hostbuilder = host.UseIISIntegration()
            .Build();

            hostbuilder.Run();
        }
    }

This allows me to run kestrel in https locally, but use IIS for https when deployed to Azure without throwing any missing file exceptions.

assafY commented 7 years ago

@nilavghosh you saved my life. Thanks.

li2008kui commented 7 years ago

问题解决了！原因是升级.NET Core版本后引起的问题。查看你的xxx.runtimeconfig.json文件并修改version的值。


  "runtimeOptions": {
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "1.1.2" <-- (1.1.0)此处改为安装版本即可
    },
    "configProperties": {
      "System.GC.Server": true
    }
  }
}

mikebridge commented 7 years ago

I'm getting this error too in a .NETCoreApp 1.1 application deployed to an App Service on Azure , and I've enabled every debugging thing I can find and I still can't see what's going on. This was working until I redeployed it.

After executing dotnet publish I edited this line in "web.config":

    <aspNetCore processPath="dotnet" arguments=".\Api.dll" stdoutLogEnabled="true" stdoutLogFile="%home%\LogFiles\dotnetcore" />

After uploading, the dotnetcore_*.log file shows me this:

Starting on http://0.0.0.0:5000
warn: Microsoft.AspNetCore.Server.Kestrel[0]
      Unable to bind to http://localhost:31657 on the IPv6 loopback interface.
System.AggregateException: One or more errors occurred. (Error -4090 EADDRNOTAVAIL address not available) ---> Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvException: Error -4090 EADDRNOTAVAIL address not available
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.tcp_bind(UvTcpHandle handle, SockAddr& addr, Int32 flags)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvTcpHandle.Bind(ServerAddress address)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.TcpListener.CreateListenSocket()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Listener.<StartAsync>b__8_0(Object state)
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at System.Threading.Tasks.Task.Wait()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelEngine.CreateServer(ServerAddress address)
   at Microsoft.AspNetCore.Server.Kestrel.KestrelServer.Start[TContext](IHttpApplication`1 application)
---> (Inner Exception #0) Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvException: Error -4090 EADDRNOTAVAIL address not available
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.tcp_bind(UvTcpHandle handle, SockAddr& addr, Int32 flags)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvTcpHandle.Bind(ServerAddress address)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.TcpListener.CreateListenSocket()
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Listener.<StartAsync>b__8_0(Object state)<---

Hosting environment: Production
Content root path: D:\home\site\wwwroot
Now listening on: http://localhost:31657
Application started. Press Ctrl+C to shut down.

Is this the problem or is it just a warning? It says there's an error binding to port 31657 on IPv6, but at the end it's saying it is indeed listening on port 31657.

Other than that, I have several other directories under /LogFiles, but I've looked at all these and don't see anything that seems like an error:

/Application
/DetailedErrors
/http/RawLogs
/kudu/deployment
/kudu/trace
/SiteExtensions/Kudu
/W3SVC1142139096
ApplicationInsightsExtension.log
dotnetcore_10388_20177761539.log
eventlog.xml

The last event in EventLog.xml is:

<Event>
    <System>
        <Provider Name="IIS AspNetCore Module"/>
       <EventID>1001</EventID>
       <Level>0</Level>
       <Task>0</Task>
       <Keywords>Keywords</Keywords>
       <TimeCreated SystemTime="2017-07-07T06:15:47Z"/>
       <EventRecordID>1151159015</EventRecordID>
       <Channel>Application</Channel>
       <Computer>RD00155DFBE915</Computer>
       <Security/>
    </System>
    <EventData>
        <Data>Application 'MACHINE/WEBROOT/APPHOST/ZEPTAPI__7BE4' started process '6672' successfully and is listening on port '31657'.</Data>
    </EventData>
</Event>

Program.cs looks like this:

        public static void Main(string[] args)
        {
            var listen = "http://0.0.0.0:5000";
            var host = new WebHostBuilder()
                .UseKestrel()
                .UseUrls(listen) // for docker to work, don't use localhost
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseIISIntegration()
                .UseStartup<Startup>()
                .UseApplicationInsights()
                .Build();

            host.Run();
        }

Not sure what else to do. It's strange because I can run it in development mode on Linux, Windows and Mac both inside and outside Docker---just not Azure.

In the "Diagnose and solve problems" option, it says "Your app is healthy right now.".

raRaRa commented 7 years ago

@mikebridge I see this error for my apps as well. I don't think it's an actual issue. My apps are running fine on Azure with this initial error.

I would recommend adding more logging, e.g. in the Startup process to find out if something might be going on there.

moozzyk commented 7 years ago

EADDRNOTAVAIL for IPv6 on Azure is benign/informational and there are changes in 2.0 to not log the stack trace. See more details here: https://github.com/aspnet/KestrelHttpServer/issues/1001

mikebridge commented 7 years ago

@raRaRa & @moozzyk thanks, that at least eliminates some of the potential issues.

I found this opaque error but no idea what it means:

Application 'MACHINE/WEBROOT/APPHOST/******' with physical root 'D:\home\site\wwwroot\' failed to start process with commandline 'dotnet .\Api.dll', ErrorCode = '0x80004005 : 8000808c.

Maybe this.

Running dotnet --info from the azure portal console log gives me this:

> dotnet --info
D:\
.NET Command Line Tools (2.0.0-preview2-006497)

Product Information:
 Version:            2.0.0-preview2-006497
 Commit SHA-1 hash:  06a2093335

Runtime Environment:
 OS Name:     Windows
 OS Version:  6.2.9200
 OS Platform: Windows
 RID:         win8-x86
 Base Path:   D:\Program Files (x86)\dotnet\sdk\2.0.0-preview2-006497\

In development I'm running 1.0.4---is it using the wrong version of dotnet? I don't see any way to select the version.

The error is not particularly informative and I really have no clue what to do to get my site back up, 24 hours later. :(

mikebridge commented 7 years ago

Ok, the solution is to explicitly modify the reference in .csproj from netcoreapp1.1 to netcoreapp1.1.2:

<TargetFramework>netcoreapp1.1.2</TargetFramework>

This seems to bring up the site with no errors.

robertmclaws commented 7 years ago

I'm experiencing the same issue in Azure on a ASP.NET Core 2.0 Preview 2 app, and this is the error I'm getting in STDOUT:

Error:
  An assembly specified in the application dependencies manifest (Accrue.Web.deps.json) was not found:
    package: 'Microsoft.AspNetCore.Mvc.Razor.ViewCompilation', version: '2.0.0-preview2-final'
    path: 'lib/netcoreapp2.0/Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.dll'

  This assembly was expected to be in the local runtime store as the application was published using the following target manifest files:
    aspnetcore-store-2.0.0-preview2-final-osx-x64.xml;aspnetcore-store-2.0.0-preview2-final-linux-x64.xml

First thing that jumps out is that this version was installed using a MacOS/Linux manifest, but I've confirmed that this running on Windows.

I should point out that my .csproj file shows: <TargetFramework>netcoreapp2.0</TargetFramework>

Any ideas?

robertmclaws commented 7 years ago

UPDATE: I solved the problem by setting my RuntimeIdentifier to the same runtime as my Azure Web App, (<RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>) and redeployed. This did a full XCOPY deployment to Azure, which executed just fine.

I'm not sure that this solves the core underlying issue in Azure, but at least my code is working.

As an aside, it seems obvious that VS2017.3 should detect your Azure settings, including what version of .NET Core is installed on the server, and wherever possible, automagically do what is necessary to get your app working. I will open some feedback to that effect on the VS portal and attempt to get it the proper visibility.

davidebbo commented 7 years ago

@robertmclaws some possibly related discussion on https://github.com/Azure/app-service-announcements-discussions/issues/2

robertmclaws commented 7 years ago

Thanks @davidebbo!

robertmclaws commented 7 years ago

Did this issue ever get fixed in production?

davidebbo commented 7 years ago

I don't remember all the details on this issue, but I think Azure production is fully deployed with all known fixes.

jchadwick commented 7 years ago

I'm running into this issue, too, although I'm trying to use the .NET Core 2.0 RTM (26423) bits. Logs show this error:

Error: An assembly specified in the application dependencies manifest (MyApp.deps.json) was not found: package: 'Microsoft.ApplicationInsights.AspNetCore', version: '2.1.1' path: 'lib/netstandard1.6/Microsoft.ApplicationInsights.AspNetCore.dll' This assembly was expected to be in the local runtime store as the application was published using the following target manifest files: aspnetcore-store-2.0.0-rtm-26423-linux-x64.xml;aspnetcore-store-2.0.0-rtm-26423-osx-x64.xml;aspnetcore-store-2.0.0-rtm-26423-win7-x64.xml;aspnetcore-store-2.0.0-rtm-26423-win7-x86.xml

Tratcher commented 7 years ago

The 2.0 RTM Azure deployment has only just started. https://github.com/Azure/app-service-announcements-discussions/issues/6

jchadwick commented 7 years ago

Figured that was the case. Thanks for the update - will watch that thread.

Triwaters commented 7 years ago

Hi all,

Apologies up front, I am basically new to .NET. I read this discussion top to bottom, as I am encountering the same error message. Open to thoughts if anyone has any. Here is what I figured out in my situation. I have .NET Core 2.0 API. If I remove web.config and publish to Azure, the API works. Inside the web.config file in my project (yes, on recompile it reappears), I have


<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" forwardWindowsAuthToken="false" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

After banging my head against the wall for about a day, I realize now why the same API fails if I proceed to publish a second time. On the second pass (assuming I do not manually remove web.config first), the web.config file is edited (again, not by me, but by the compiler) and now looks like this:


<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />
  </system.webServer>
</configuration>

At which point Azure throws our beloved error message.

If I remove web.config and start over, the API is happy (1st publish) and then sad (2nd publish) in reliable sequence.

What I can't figure out is what to do about it. I'm not the one putting two flavors of web.config together. The compiler is doing it.

Thoughts? Again, I'm very new to virtually everything start to finish... so there are a thousand things I might be doing wrong in my learn-everything never-done-this-before project.

post-note: I may have found my answer: I am perusing this now, and it looks very promising...

https://docs.microsoft.com/en-us/aspnet/core/publishing/iis

Tratcher commented 7 years ago

@wstllc Yeah, that looks like a tooling bug. Please report it to the tooling team via the VS "Send Feedback" tool.

Triwaters commented 7 years ago

Thx for thoughts, Tratcher, but before I bother them, here's what I figured out. (Bug? Feature? I'm too new to know...)

What I worked out did not involve removing the web.config file, so let that thought be. In below comments, presume file remains and is never deleted.

It turns out that if I do the following steps, publishing will succeed: 1) Use IIS Express profile 2) RUN it locally first, and THEN 3) Publish to Azure

Guaranteed routes to failure: Option #1: Use IIS profile, run app locally, then publish. Option #2: Use IIS profile, switch back to IIS Express and publish without first running under the Express profile.

In short, the web.config version last used when the project runs locally is what gets published, regardless of which profile you happen to have selected at the moment.

What I don't myself understand is why IIS Express uses this (which works great when publishing to Azure)...

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />
  </system.webServer>
</configuration>

...whereas IIS uses this (which is toxic to all API life forms on Azure)...

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />
  </system.webServer>
</configuration>

One other thing: By "run" I mean "Click the green triangle". I can build the project with the IIS Express profile selected and then deploy it to a a soul-crushing failure on Azure if the last "run" was under the IIS profile.

I have to not merely select IIS Express but also cause a local browser to open as well -- only the opening of the browser causes web.config to get updated to the lovely version that works well in Azure.

Tratcher, if you think that's a bug in Visual Studio, I'll do as you suggest -- otherwise I'll chalk this all up "part of my learning curve."

Thanks!

Tratcher commented 7 years ago

Definitely a bug. You should never end up with VSIISExeLauncher in your process path after publish. Please report it to VS.

Triwaters commented 7 years ago

Did so -- thx for feedback

mihirdilip commented 7 years ago

I came across the similar issue when I deployed asp.net core 2.0 on Azure. I fixed it by removing -argFile IISExeLauncherArgs.txt from below

<aspNetCore processPath="dotnet" arguments=".\xyz.dll -argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

so it looks like

<aspNetCore processPath="dotnet" arguments=".\xyz.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

I also tried by adding a dummy IISExeLauncherArgs.txt file but it didn't work. Removing it worked for me. I hope this helps someone..

davidebbo commented 7 years ago

mlawand commented 7 years ago

i am facing the same issue, and i have tried all of the solutions in the thread but its not working.

i have a asp.net core 2.0 application which was working perfectly today it stopped suddenly and i am getting the issue

502 - Web server received an invalid response while acting as a gateway or proxy server. There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server. or this The specified CGI application encountered an error and the server terminated the process.

since my application was asp.net core 1.1 and i have updated it to 2.0 i deleted the wwwroot folder and reuploaded the application still it doesnt work.

the application works perfectly locally

this is the webconfig

`<?xml version="1.0" encoding="utf-8"?>

` Program.cs

` public class Program { public static void Main(string[] args) { BuildWebHost(args).Run(); }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

}`

Startup.cs

`public class Startup { public Startup(IConfiguration configuration) { Configuration = configuration;

        var appConfig = configuration.GetSection("Configuration").Get<Configuration>();
    }

    public IConfiguration Configuration { get; }

    // This method gets called by the runtime. Use this method to add services to the container.
    public void ConfigureServices(IServiceCollection services)
    {
        // Add framework services.
        services.AddDbContext<ApplicationDbContext>(options =>
            options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

        services.AddLocalization(opts => { opts.ResourcesPath = "Resources"; });

        services.AddIdentity<ApplicationUser, IdentityRole>(options =>
        {
            options.Password.RequiredLength = 8;
            options.Password.RequireUppercase = true;
            options.Password.RequireDigit = true;
            options.Lockout.MaxFailedAccessAttempts = 5;
            options.Password.RequiredUniqueChars = 5;
        })
        .AddEntityFrameworkStores<ApplicationDbContext>()
        .AddDefaultTokenProviders();
        // .AddPasswordValidator<UsernameAsPasswordValidator<ApplicationUser>>();

        services.ConfigureApplicationCookie(Options => Options.LoginPath = "/Account/Login");
        services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme);

        services.AddSession(options =>
        {
            options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
            options.Cookie.HttpOnly = true;
            options.IdleTimeout = TimeSpan.FromMinutes(20);
        });

        // Add framework services.
        services.AddMvc(
          //options => { options.Filters.Add(new RequireHttpsAttribute()); }
        ).AddViewLocalization(
            LanguageViewLocationExpanderFormat.Suffix,
            opts => { opts.ResourcesPath = "Resources"; })
            .AddDataAnnotationsLocalization();

        services.Configure<RequestLocalizationOptions>(
            opts =>
            {
                var supportedCultures = new List<CultureInfo>
                {
                                new CultureInfo("ar-AE"),
                                new CultureInfo("en")
                };

                opts.DefaultRequestCulture = new RequestCulture("en");
                // Formatting numbers, dates, etc.
                opts.SupportedCultures = supportedCultures;
                // UI strings that we have localized.
                opts.SupportedUICultures = supportedCultures;
            });

        services.Configure<FormOptions>(x =>
        {
            x.ValueLengthLimit = Int32.MaxValue;
            x.MemoryBufferThreshold = Int32.MaxValue;
            x.MultipartBodyLengthLimit = Int32.MaxValue; // In case of multi-part
        });

        services.AddScoped<IApplicationContext, ApplicationContext>();

        // Add application services.
        services.AddTransient<IEmailSender, AuthMessageSender>();
        services.AddTransient<ISmsSender, AuthMessageSender>();

        services.AddSingleton(HtmlEncoder.Create(allowedRanges: new[] { UnicodeRanges.Arabic }));

        services.Configure<AuthMessageSenderOptions>(Configuration);
    }

    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)//, ContextDataSeeding seeder)
    {
        loggerFactory.AddConsole(Configuration.GetSection("Logging"));
        loggerFactory.AddDebug();

        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
            app.UseDatabaseErrorPage();
            app.UseBrowserLink();
        }
        else
        {
            app.UseExceptionHandler("/Home/Error");

            // Force HTTPS
            //var optionsHttps = new RewriteOptions().AddRedirectToHttps();
            //app.UseRewriter(optionsHttps);
        }

        // Get the main user for this client
        // seeder.SeedAdminUser();

        //app.UseInMemorySession(configure: s => s.IdleTimeout = TimeSpan.FromMinutes(30));
        app.UseSession();
        app.UseStaticFiles();

        var options = app.ApplicationServices.GetService<IOptions<RequestLocalizationOptions>>();
        app.UseRequestLocalization(options.Value);

        // custom middle-wear
        app.UseApplicationContext();
        //app.UseStorageInitializer();

        app.UseAuthentication();

        // Add external authentication middle ware below. To configure them please see https://go.microsoft.com/fwlink/?LinkID=532715

        app.UseMvc(routes =>
        {
            routes.MapRoute(
                name: "default",
                template: "{controller=Digital}/{action=Index}/{id?}");
        });
    }
}`

Error Log: `warn: Microsoft.AspNetCore.Server.Kestrel[0] Unable to bind to http://localhost:10949 on the IPv6 loopback interface: 'Error -4090 EADDRNOTAVAIL address not available'. warn: Microsoft.AspNetCore.Server.Kestrel[0] Unable to bind to http://localhost:10949 on the IPv6 loopback interface: 'Error -4090 EADDRNOTAVAIL address not available'. Hosting environment: Production Content root path: D:\home\site\wwwroot Now listening on: http://localhost:10949 Application started. Press Ctrl+C to shut down. Assert Failure Expression: [Recursive resource lookup bug] Description: Infinite recursion during resource lookup within System.Private.CoreLib. This may be a bug in System.Private.CoreLib, or potentially in certain extensibility points such as assembly resolve events or CultureInfo names. Resource name: ArgumentNull_Generic Stack Trace: at System.SR.InternalGetResourceString(String key)

at System.SR.GetResourceString(String resourceKey, String defaultString)

at System.ArgumentNullException..ctor(String paramName)

at System.Runtime.Loader.AssemblyLoadContext.GetLoadContext(Assembly assembly)

at System.Reflection.Assembly.LoadFromResolveHandler(Object sender, ResolveEventArgs args)

at System.AppDomain.OnAssemblyResolveEvent(RuntimeAssembly assembly, String assemblyFullName)

at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks, IntPtr ptrLoadContextBinder)

at System.Reflection.RuntimeAssembly.InternalGetSatelliteAssembly(String name, CultureInfo culture, Version version, Boolean throwOnFileNotFound, StackCrawlMark& stackMark)

at System.Resources.ManifestBasedResourceGroveler.GetSatelliteAssembly(CultureInfo lookForCulture, StackCrawlMark& stackMark)

at System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(CultureInfo culture, Dictionary`2 localResourceSets, Boolean tryParents, Boolean createIfNotExists, StackCrawlMark& stackMark)

at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo requestedCulture, Boolean createIfNotExists, Boolean tryParents, StackCrawlMark& stackMark)

at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)

at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)

at System.SR.InternalGetResourceString(String key)