We Keep Coding

HTTP Error 502.5 - ANCM Out-Of-Process Startup Failure after upgrading to ASP.NET Core 2.2

After upgrading my project to ASP.NET Core 2.2, I tried to run the application (locally of course) and the browser displayed an error message like in the below screenshot.
no more errors notified by visual studio error explorer. I don't know what's happen.

In my case, I upgraded some nuget packages to net core 2.2, but I did not have the net core 2.2 sdk installed, so I went to net core website to download the latest sdk or runtime package, and then I did a net stop was /y and then a net start w3svc in the CMD as administrator. Problem solved for me.

I encountered this error after trying to publish from VS2017 to the production Windows 2016 server. (It worked fine in IIS Express on my local Win10 PC.)
I updated packages, all versions matching and updated in my code, .net core versions matching, restart IIS, rebooting... no joy.
In the Publish > Configure > Settings (left tab) I had to set the Target-runtime from "Portable" to "win-x64" (or whatever is relevant to your environment). I also opted to "Remove additional files at destination."
"Portable" is the default setting. I'm not sure what it takes for the "Portable" runtime to work properly, but might save someone else some time if a "Portable" runtime is not something you need.
Generally speaking, I get this error if something is mismatched in my environment. For example, one time I was upgrading one of my projects to .Net Core 3.1 from 2.2 and hadn't installed the ASP.NET Core Runtime Hosting Bundle on my server:
https://dotnet.microsoft.com/download/dotnet-core/3.1
Also, you can get this error if your Application Pool is set to True for Enable 32-Bit Applications. Try:
IIS Manager > Application Pools > app pool name > (right click) Advanced
Settings > Enable 32-Bit Applications = False

I ran into this issue and had a different solution. For me it was that I had a package that was out of date with the application (I had updated it on NuGet, and the library hadn't been replaced in production). Updating the package fixed it for me.
Note with this: I had to manually run dotnet.exe with the project dll in order to see the message that fixed it for me.
Hope this helps someone else down the road.

you have 2 solution(this answer works on windows server I do not know anything about linux server).
first:
copy all folder(except bin and obj folder) of your project to server
open cmd in your project folder then run this command: dotnet run then all warning and error show to you(if you have error about above command not recognize download dot net core sdk from this link)
second:
you must changed hostingModel attribute from OutOfProcess to
inprocess in web.config and you can change stdoutLogEnabled to true
value for get your project error in logs folder
read your projects errors and fix those.
in my case web.config is:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\BMS.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="OutOfProcess" />
</system.webServer>
</location>
</configuration>
and I change it to:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\BMS.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
</system.webServer>
</location>
</configuration>

In my case it was the log level set incorrectly in the appsettings.json. Instead of Warning I've had Warn and this crashed the app with above error.

Seems that everyone has a different answer for this. I also had this issue as well. There are many different things as you can tell that cause this issue. If you don't find any of these solutions helpful or have issues trying to go through all these different solutions, you can try running your application from the command line from the publish folder.
After publish, if you receive this error, go to your publish folder, and then open a command/terminal window, after that type dotnet .\YourStartupProject.dll, you should receive an exception error, which should make fixing the issue easier.
For example, this is an error I received on trying on a new environment without setting up a SQL server, and of course, would receive this error.
Application startup exception: System.Exception: Could not resolve a service of type
'YourStartupProject.DataServices.DbContext.DbContext' for the parameter
'context' of method 'Configure' on type 'YourStartupProject.Startup'. --->
System.ArgumentNullException: Value cannot be null.
Parameter name: connectionString
Once you resolve your error, try it again, rinse, repeat.

For me the issue was caused by dotnet publish creating a web.config entry stdoutLogFile=".\logs\stdout". The correct value should be stdoutLogFile="\\?\%home%\LogFiles\stdout".
MSDN reference: https://blogs.msdn.microsoft.com/waws/2018/06/10/troubleshooting-http-502-5-startup-issues-in-azure-appservice-for-asp-net-core-websites/
This could be a bug in the ASP.NET Core 2.2.0 runtime which may have been fixed in a later version.

Follow this steps:
create a directory in root of your project : logs/stdout
open the web.config file from root of your project and find this line:
<aspNetCore processPath=".\web.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
set stdoutLogEnabled as true and save it
reload your app and see the logs in the directory : logs/stdout

I ran into this issue today with my hosting - locally everything is ok but once I publish, I get this error.
I looked through the packages and found out that some .net core stuff was upgraded to 3.0 preview.
Then I changed the build option in VS2019 from "Framework-Dependent" to "Self-contained". It took 5 times longer to build and publish but now it works.
Now I'm checking with host tech support what might be an issue - officially they support 2.1 / 2.2 only, so this might be these packages from 3.0 Preview, however target build is 2.2.

My issues was malformed appsetttings.json file. I enabled standard out logging via web.config and was able to get the underlying exception throwing this error.

If resetting the project and manually copying Program and Startup classes worked for you, then something was clearly messed up. There are some bigger underlying problems with this. Using the OutOfProcess hosting model is okay, but with .Net Core 2.2 you should be able to use the InProcess hosting model, since it is naturally faster: everything is processed in IIS, without an extra HTTP-hop between IIS and your app's Kestrel server.
If you right-click your project file in the visual studio solution explorer, please make sure that AspNetCoreModuleName tag has AspNetCoreModuleV2 value (as opposed to the older AspNetCoreModule). Also, examine Windows Application Event Log to identify the potential culprit. Even though error messages there are somewhat cryptic, they might point you to the exact line number in the code that caused the failure.
Finally, in case you use CI/CD with TFS, there may be environment variable(s) in appsettings.json file that were not properly replaced with the actual values (URLs, etc.).

Looks like i had the same issue. It's happens because if you don't have global.json file in solution, then VS build(publish) .net core app with the last version that installed on your pc. So, i do the next solution:
add a global.json file with .net core version.
{
"sdk": {
"version": "2.2.402"
}
}
From learn.microsoft.com:
global.json can be placed anywhere in the file hierarchy. The CLI searches upward from the project directory for the first global.json it finds. You control which projects a given global.json applies to by its place in the file system. The .NET CLI searches for a global.json file iteratively navigating the path upward from the current working directory. The first global.json file found specifies the version used. If that version is installed, that version is used. If the SDK specified in the global.json is not found, the .NET CLI rolls forward to the latest SDK installed. Roll-forward is the same as the default behavior, when no global.json file is found.
https://learn.microsoft.com/en-us/dotnet/core/versions/selection

This happened to me when I deployed code using Entity Framework Core with migrations, and there was mismatch between the state of the database and the migrations in the code.

This happened to me first time publishing an Azure Web App. Here is how I solved it:
Browse the site using Kudo/FTP. In the root folder there is a LogFiles folder where you find eventlog.xml. In this file I could see that my web app had an SqlException when Entity Framework Core was trying to setup the database, which lead me to check the database permissions (which was the problem for me).

This is what worked for me:
- I ran the startup file of the project in the deployed (IIS) folder. Note that: this will not solve the problem but will inform you about what the problem is. In my case, the cause of the problem was a database migration that failed

Another answer that might help other people in the same case: we have an AppService on Azure where there are 3 NETCore project deployed on 3 different path:
One for Web (/webapi)
One for Mobile (/mobileapi)
One for Functions serverless, in our case was it was AzureFunctions (/functionapi)
Since the upgrade to NETCore3.x, we understood that the hosting model by default was "In-Process" so we had to edit the .csproj file to explictly set the hosting model to "Out-Of-Process" like this:
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
</PropertyGroup>
But it was not enough: in fact, we also have to edit Program.cs. Why ? Because in Program.cs the one generated by default in NETCore3.x you have the following code:
public static IHostBuilder CreateHostBuilder(string[] args)
{
return Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
webBuilder.ConfigureKestrel(o => o.AddServerHeader = false);
});
}
When we replaced this by the old code by NETCore2.x version like below:
public static IWebHostBuilder CreateWebHostBuilder(string[] args)
{
return WebHost.CreateDefaultBuilder(args)
.UseKestrel(options => options.AddServerHeader = false)
.UseStartup<Startup>();
}
After deployment, the error 502.5 ANCM Startup Failure was gone :) Hope this answer can help other people.
BTW I know this post is related to NETCore2.2, we also met the same problem but we decided to switch to NETCore3.1 because NETCore2.2 was no more supported and this version was also buggy on some other points.

My .NET Core site was worked fine, but after a while, I got this error (HTTP Error 502.5 - ANCM Out-Of-Process Startup Failure ...);
I tried different methods. Finally I Add new web site in IIS (with other port), then the error was solved.

I got this issue in ASP.NET Core 2.2 project and its resolved for me just by Clean and Rebuild project.

This error started appearing on our Dev server. I had been using this publish command which creates a "self-contained" folder of files for deployment.
dotnet publish -c release -r win7-x64 --output:bin/self_contained
My fix was to instead publish a "framework-dependent" deployment using the following command:
dotnet publish --output:bin/framework_dependent
The dev server did have a few versions of .NET Core installed (2.2.3 and 2.2.5) in this folder *C:\Program Files\dotnet\shared
I am still not clear on why the self contained publish does not work. You might think the self contained publish would be the more reliable method, but in my case it was not.
This .NET Core blog post was helpful.

I got this same error while deploying .Net core app which was targeting .Net framework on Windows server. I checked event viewer on the server and turns out server didn't have .net 4.7.2 installed.
Installing it resolved issue for me.

Yet another scenario that caused this issue for me:
I am running the app pool identity with a service account and I had to run dotnet dev-certs https under this user to get rid of "System.InvalidOperationException: Unable to configure HTTPS endpoint." during startup.

Be carefull publishing.
When i publish it to my PreProd envitoment this conf works well:
Portable
But on my Prod enviroment that conf does not work. I had to choose the especificated one:
win-x64
I dont know the reason about that. If someone know i'll gratefull to know!

The problem occurs when I try to deploy the asp.net core (out-of-process hosting model) website to windows server 2012r2 IIS in production env.
I fixed this with this solution:
Change application pool identity to administrator.

Same failture happent on project publish.
The issue ralated with the latest Microsoft.AspNetCore.App package. Just downcast it from from 2.2.x to 2.2.0
or goto dotnet.microsoft.com/download/dotnet-core/2.2 and get newest dotnet-hosting installer

I was also getting the same issue. And when I looked at the Output window of my solution.
Then I was able to see a different error, which is "The target process exited without raising CoreCLR started event", to fix this I had to remove the Microsoft.AspNetCore.All from my Nuget Packages and install Microsoft.AspNetCore.App. I also had to install the correct .Net SDK from here. Once this is done, restarted my machine and open the solution, the error was gone. Hope it helps

If you are working with ASP.Net Core version 2.2 then in appsettings.json just comment the line -
"AllowedHosts": "*"
it resolves the issue. My application working fine.

This error can be happened because of many reasons. In my case it was an exception due to invalid format of appsettings.json . How I found out is by enabling stdout log in web.config.

For me the issue was a missing appsettings.json
I select the appropriate appsettings.json file (appsettings.production.json or appsettings.development.json) based on an environment variable. Turns out the appsettings.json is required even if you dont use it.

My problem was with the web.config file after publishing. The processPath in the aspNetCore tag was missing the file extension. In my case it was .exe

In my case EF Migrations thrown exception about blocking executing one of them because of a potential data loss.
I had to look into custom app logs (most often Log folder) to find out that.
I guess the Error mentioned in the Question is due to problems during app start stage. And indeed the migrations are run during starting an app, so if they fail the app is not able to complete starting.
So in general when we get such Error we should focus on things that impact on starting logic of the app.

ASP.NET Core failed to publish on IIS, gives HTTP error 502.5

I am trying to publish an ASP.NET Core 2.0 Webapplication (MVC) to IIS. But I get the HTTP error 502.5.
I have tried the following:
I looked at the event log from Windows, I found the following message; "Application 'MACHINE / WEBROOT / APPHOST / LEVISTEENBERGEN' with physical root C: \ Websites \ levisteenbergen.com \ 'failed to start process with commandline' dotnet. \ Levi Steenbergen.dll ', ErrorCode =' 0x80004005: 1." I still don't how to solve this problem.
Enabled the 'stdout' in the web.config file, but no log directory was created.
Can someone please help me with this?

This question is not an exact duplicate because it is referring to .NET Core 1.0.1 and yours is about .NET Core 2.0, but I believe the solution is the same:
You need to install the correct .NET Core 2.x SDK version on the target machine, as it is most likely missing.

I have seen this happen when you have an exception in your Startup class.
As the other comment mentioned, I've also seen this when the path is incorrect for the aspNetCoreProcess on the web.config

I had the same problem.
You have to enabled the 'stdout' in the web.config file, but also, create a folder with 'logs' otherwise logs will not be created

make sure to check the box for publish to wipe out files on push to server there is remnants of 1.0.1 if that was previously used. Folder needs to cleansed. This happens on Azure. Other potential is to force a framework version in the project where the server might not have the updated bits.

ASP.NET Core 1.0 on IIS error 502.5 - Error Code 0x80004005

I just updated my server (Windows 2012R2) to .NET Core 1.0 RTM Windows Hosting pack from the previous .NET Core 1.0 RC2. My app works on my PC without any issues but the server keeps showing:
HTTP Error 502.5 - Process Failure
Common causes of this issue:
The application process failed to start
The application process started but then stopped
The application process started but failed to listen on the configured port
It previously worked with the RC2 version. Don't know what could go wrong.
This is all event viewer says:
Failed to start process with the commandline 'dotnet .\MyWebApp.dll'. Error code = '0x80004005'.
the worst part is that app logs are empty! I mean those stdout_xxxxxxxxx.log files are completely empty and all have 0 byte size.
What should I do?? How can I know the cause of error when it's not logged??

I was able to fix it by running
"C:\Program Files\dotnet\dotnet.exe" "C:\fullpath\PROJECT.dll"
on the command prompt, which gave me a much more meaningful error:
"The specified framework 'Microsoft.NETCore.App', version '1.0.1' was
not found.
- Check application dependencies and target a framework version installed at:
C:\Program Files\dotnet\shared\Microsoft.NETCore.App
- The following versions are installed:
1.0.0
- Alternatively, install the framework version '1.0.1'.
As you can see, I had the wrong NET Core version installed on my server. I was able to run my application after uninstalling the previous version 1.0.0 and installing the correct version 1.0.1.

I had the same problem, in my case it was insufficient permission of the user identity of my Application Pool, on Publishing to IIS page of asp.net doc, there is a couple of reason listed for this error:
If you published a self-contained application, confirm that you didn’t set a platform in buildOptions of project.json that conflicts with the publishing RID. For example, do not specify a platform of x86 and publish with an RID of win81-x64 (dotnet publish -c Release -r win81-x64). The project will publish without warning or error but fail with the above logged exceptions on the server.
Check the processPath attribute on the <aspNetCore> element in web.config to confirm that it is dotnet for a portable application or .\my_application.exe for a self-contained application.
For a portable application, dotnet.exe might not be accessible via the PATH settings. Confirm that C:\Program Files\dotnet\ exists in the System PATH settings.
For a portable application, dotnet.exe might not be accessible for the user identity of the Application Pool. Confirm that the AppPool user identity has access to the C:\Program Files\dotnet directory.
Confirm that you have correctly referenced the IIS Integration middleware by calling the .UseIISIntegration() method of the application’s WebHostBuilder().
If you are using the .UseUrls() extension method when self-hosting with Kestrel, confirm that it is positioned before the .UseIISIntegration() extension method on WebHostBuilder(). .UseIISIntegration() must set the Url for the reverse-proxy when running Kestrel behind IIS and not have its value overridden by .UseUrls().
In my case it was the fourth reason, I changed it by right clicking my app pool, and in advanced setting under Process Model, I set the Identity to a user with enough permission:

I got this working with a hard reset of IIS (I had only just installed the hosting package).
Turns out that just pressing 'Restart' in IIS Manager isn't enough. I just had to open a command prompt and type 'iisreset'

So I got a new server, this time it's Windows 2008R2 and my app works fine.
I can't say for sure what the problem was with the old server but I have one idea.
So because I previously compiled the app without any platform in mind it gave me the dll version which only works if the target host has .Net Core Windows Hosting package installed. In my case it was installed and that was fine.
After the app didn't work I decieded to compile it as a console app with win7-x64 as runtime. This time the moment I ran the exe of my app on the server, it crashed with an error about a missing dll:
The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing
That dll is from Universal C Runtime that's included in the Visual C++ Redistributable for Visual Studio 2015.
I tried to install that package (both x64 & x86) but it failed each time (don't know why) on Windows Server 2012 R2.
But when I tried to install them in the new server, Windows Server 2008 R2, they successfully installed. That might have been the reason behind it, but still can't say for sure.

I had the same issue when publishing the web app.
If anybody still has this problem fixed it by changing {AppName}.runtimeconfig.json
{
"runtimeOptions": {
"framework": {
"name": "Microsoft.NETCore.App",
"version": "1.1.2"
},
"configProperties": {
"System.GC.Server": true
}
}
}
Change the version from "version": "1.1.2" to "version": "1.1.1" and everythign worked ok

I had the same problem.
To find out the exact source of it I switched on logging in
web.config file:
<aspNetCore processPath="dotnet" arguments=".\MyWebService.dll" stdoutLogEnabled="**true**" stdoutLogFile=".\logs\stdout" />
and created logs subfolder in MyWebService root folder.
After restarting IIS and trying to execute API I got an error and it was missing of proper Core Runtime. After downloading an installing DotNetCore.1.0.5_1.1.2-WindowsHosting the error gone.

Had the same issue and all solutions didn't work. Found this gem and thought I'd pass along if it helps someone else. Install on Server 2012 R2 getting the DLL missing error, try to reinstall VS C++ 2015 and get an error. Fix is to do the following:
Seems the file
C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msu has problems being installed.
Open admin command prompt do:
c:
mkdir tmp
mkdir tmp\tmp
move "C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msu" c:\tmp
expand -F:* c:\tmp\Windows8.1-KB2999226-x64.msu c:\tmp\tmp
dism /online /add-package /packagepath:c:\tmp\tmp\Windows8.1-KB2999226-x64.cab
NOTE: replace the "..." with the correct folder name. After this reinstall the VS C++ 2015 package.

I had a similar issue, and to quote Sherlock Holmes:
"when you have eliminated the impossible, whatever remains, however improbable, must be the truth?"
I checked if the .NET framework I was targeting was installed on the server, and it turns out it wasn't. I installed the 4.6.2 .NET Framework and it worked.

I got this issue on my production server after my VS project was automatically upgraded to .NET Core 1.1.2.
I simply installed the 1.1.2 .net core runtime from here on my production server: https://www.microsoft.com/net/download/core#/runtime

SOLVED I just ran through the same issue today while deploying to AZURE. Then I tried the same for local IIS, got the same issue. As I am new to .net CORE, struggled few hour before I actually solved it.
In our solution, after I publish to IIS, I observed my web.confile file, specially below line <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />
In our deployment folder the generated web.config looks like:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll -argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
Now PLEASE try changing the above configuration in visual studio solution to<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />
In our new deployment folder the generated web.config looks like:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
And This SOLVED my problem, Hope it help.

I had the same problem when I updated my dev machine to Core 1.0.1, but forgot to update the server.

I was getting HTTP Error 502.5 while trying to publish my .NET Core 2.0 API to AWS EB, and solved it by adding the following code to the .csproj:
<PropertyGroup>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>

I had a same issue . I changed application pool identity to network service account . Then I explicitly set the path to dotnet.exe in the web.config for the application to work properly as #danielyewright said in his github comment . It works after set the path.
Thanks

Sharing that in my case this error was because i forgot to update project.json with:
"buildOptions": {
"emitEntryPoint": true
}

I had the same error in question, with the same issues as described by VSG24 in Proposed answer - nasty error message when typing 'dotnet' into CMD:
The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing
I solved this by manually installing the following 2 updates on Windows Server 2012 R2 (and the pre-requisites and all the other updates linked - read the installation instructions carefully on the Microsoft website):
KB2919355
KB2999226
Hope this helps someone.

I faced the same issue when I tried to publish Debug version of my web application. This set of files didn't contain the file web.config with the proper value of attribute processPath.
I took this file from Release version, value was assigned to the path to my exe file.
<aspNetCore processPath=".\My.Web.App.exe" ... />

In my case was problem with Net Core version installed on server.
I just install the same version as on my development machine and everything is OK :-)

Here is what I figured, and this happened recently on Windows 10 after an update was installed. From what I gathered, a Windows Defender update was installed which assumed my "Project.dll"(an asp.net core project) behaved like a virus so it was deleted.
So, one of the first things I suggest you do before you start installing/uninstalling stuffs is to check to confirm your "Project.dll" is where it should be.
Copy it back to the location if it is no longer there.
If you are having difficulty copying the file back add an exclusion to your project folder in windows defender. ( Learn how to do that here. )
This worked for me instantly, and I repeated it across application multiple servers.

I needed to install the latest .net Core version found here.
No need to restart the site or server

I solved it by adding "edit permission" to the application of the site, mapped to the physical directory and then selected the windows user that could have access to this root folder. (private network).

In my case, after installing AspNetCore.2.0.6.RuntimePackageStore_x64.exe and DotNetCore.2.0.6-WindowsHosting.exe , I need to restart server to make it worked without 502 bad gateway and proxy error.
UPDATE:
There is a way you could use it without restart:
https://stackoverflow.com/a/50808634/3634867

Open command prompt with Administrator credentials
Type following command and hit enter
> IISRESET
OR
Open Visual Studio 2017 with Administrator credentials
Type following command in Package Manager Console and hit enter
PM> IISRESET
PM> IISRESET
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted

I had this problem aswell (The error occurred both on VS 15 and 17). However on VS15 it returned a CONNECTION_REFUSED error and on VS17 it returned ASP.NET Core 1.0 on IIS error 502.5.
FIX
Navigate to your project directory and locate the hidden folder .vs (it's located in the projects folder dir). (Remember to show hidden files/folders)
Close VS
Delete .vs-folder
Start VS as admin (.vs-folder will be recreated by VS)

For me it was that the connectionString in Startup.cs was null in:
services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
and it was null because the application was not looking into appsettings.json for the connection string.
Had to change Program.cs to:
public static void Main(string[] args)
{
BuildWebHost(args).Run();
}
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.ConfigureAppConfiguration((context, builder) => builder.SetBasePath(context.HostingEnvironment.ContentRootPath)
.AddJsonFile("appsettings.json").Build())
.UseStartup<Startup>().Build();

I have no idea why this worked for me, but I am using Windows Authentication and I had this bit of code on my BuildWebHost in Program.cs:
.UseStartup<Startup>()
.UseHttpSys(options =>
{
options.Authentication.Schemes =
AuthenticationSchemes.NTLM | AuthenticationSchemes.Negotiate;
options.Authentication.AllowAnonymous = false;
})
.Build();
After removing the .UserHttpSys bit, it now works, and I can still authenticate as a domain user.
BuildWebHost now looks like
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.Build();

I was getting the same error, and found out the problem was that during the publish to Azure, my web.config file was modified so this following line ended up like this:
<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" startupTimeLimit="3600" requestTimeout="23:00:00" />
The problem for Production are the contents of the arguments: "-argFile IISExeLauncherArgs.txt"
It seems like this issue is going to be addressed in the next .NET Core SDK (currently in preview), but for now, the workaround is to add this block to the .csproj file:
<Target Name="bug_242_workaround" AfterTargets="_TransformWebConfig">
<Exec Command="powershell "(Get-Content '$(PublishDir)Web.config').replace(' -argFile IISExeLauncherArgs.txt', '') | Set-Content '$(PublishDir)Web.config'"" />
</Target>
This will modify the web.config and remove the problematic part for publishing.
Reference: https://github.com/aspnet/websdk/issues/242
Hope it helps.

Worked for me after changing the publishing configuration.

For me it was caused by having different versions of .Net Core installed. I matched my dev and production server and it worked.

I had a similar issue (Asp.Net Core 2.x) that was caused by trying to run a 32-bit asp.net core app in IIS on a 64-bit windows server. The root cause was that the web.config that is auto-generated (if your project does not explicitly include one, which asp.net core projects do not by default) does not contain the full path to the dotnet executable. When you install the hosting bundle on a 64 bit machine it will install the 64 and 32 bit versions of dotnet, but the path will resolve by default to 64 bit and your 32 bit asp.net core app will fail to load. In your browser you may see a 502.5 error and if you look the server event log you might see error code 0x80004005. If you try to run dotnet.exe from a command prompt to load your asp.net core application dll on that server you may see an error like "BadImageFormatException" or "attempt was made to load a program with an incorrect format". The fix that worked for me was to add a web.config to my project (and deployment) and in that web.config set the full path to the 32-bit version of dotnet.exe.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="C:\Program Files (x86)\dotnet\dotnet.exe" arguments=".\My32BitAspNetCoreApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
</system.webServer>
</location>
</configuration>

I got the same problem and the reason in my case was that the EF core was trying to read connection string from appsettings.development.json file. I opened it and found the connection string was commented.
//{
// "ConnectionStrings": {
// "DefaultConnection": "Server=vaio;Database=Goldentaurus;Trusted_Connection=True;",
// "IdentityConnection": "Server=vaio;Database=GTIdentity;Trusted_Connection=True;"
// }
//}
I then uncommitted them like below and the problem solved:
{
"ConnectionStrings": {
"DefaultConnection": "Server=vaio;Database=Goldentaurus;Trusted_Connection=True;",
"IdentityConnection": "Server=vaio;Database=GTIdentity;Trusted_Connection=True;"
}
}

Problems with deploy ASP.NET 5 (ASP.NET Core) app to Azure

I have an app on ASP.NET 5 (CoreCLR) and I try to publish it to the Microsoft Azure. I using free Web App (not VDS)
I am publishing app using Visual Studio 2015 Publish->Microsoft Azureand following this instructions.
But when I publish it and try to open, I see just non-stop loading of empty page. I enabling logging and view the log (stdout.log) from Azure and there was only:
'"dnx.exe"' is not recognized as an internal or external command,
operable program or batch file.
Also I tried to do Continiusly publishing with git. During push, It started restoring packages and failed with error no disk space available.
Is there any way to publish ASP.NET 5 app to the Azure Web App?

Short Answer
But when I publish it and try to open, I see just non-stop loading of empty page.
This happens when our app fails to publish the runtime (dnx.exe) with the application.
Discussion
There are several ways to publish ASP.NET Core rc1 apps to an Azure Web App. These include continuous deployment with Git and publishing with Visual Studio. Post your repository's contents for specific help.
The example is an ASP.NET Core rc1 app, deployed to an Azure Web App, via GitHub continuous deployment. These are the vital files.
app/
wwwroot/
web.config
project.json
startup.cs
.deployment <-- optional: if your app is not in the repo root
global.json <-- optional: if you need dnxcore50 support
app/wwwroot/web.config
Add the HttpPlatformHandler. Configure it to forward all requests to a DNX process. In other words, tell the Azure Web app to use DNX.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="httpPlatformHandler"
path="*" verb="*"
modules="httpPlatformHandler"
resourceType="Unspecified"/>
</handlers>
<httpPlatform
processPath="%DNX_PATH%"
arguments="%DNX_ARGS%"
stdoutLogEnabled="false"
startupTimeLimit="3600"/>
</system.webServer>
</configuration>
app/project.json
Include a dependency on the Kestrel server. Set a web command that will startup Kestrel. Use dnx451 as the target framework. See below for the additional work to target dnxCore50.
{
"dependencies": {
"Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final"
},
"commands": {
"web": "Microsoft.AspNet.Server.Kestrel"
},
"frameworks": {
"dnx451": { }
}
}
app/Startup.cs
Include the Configure method. This one adds an extremely simple response handler.
using Microsoft.AspNet.Builder;
using Microsoft.AspNet.Http;
namespace WebNotWar
{
public class Startup
{
public void Configure(IApplicationBuilder app)
{
app.Run(async (context) =>
{
await context.Response.WriteAsync(
"Hello from a minimal ASP.NET Core rc1 Web App.");
});
}
}
}
.deployment (optional)
If your app is not in the repositories root directory, tell the Azure Web App which directory contains the app.
[config]
project = app/
global.json (optional)
If you would like to target .NET Core, tell Azure that we want to target it. After adding this file, we can either replace (or complement) the dnx451 entry in our project.json with dnxCore50.
{
"sdk": {
"version": "1.0.0-rc1-update1",
"runtime": "coreclr",
"architecture": "x64"
}
}

Firstly, yes, you can happily run ASP.Net 5 core apps on Azure, but there are some gotchas.
I don't know why it doesn't work when you publish from Visual Studio itself (so why is he posting an answer I hear you ask...), but here are some things to have a look at;
Try running in IIS locally (rather than kestrel) - just to see if there is a problem. For example, you need a Web.config with some settings or you need the app.UseIISPlatformHandler in startup.cs.
Have a look at your global.json file. It shouldn't matter when you publish from Visual Studio but it won't hurt to set this correctly. You can do something like this:
.
{
"sdk": {
"version": "1.0.0-rc1-update1",
"runtime": "coreclr",
"architecture": "x64"
}
}
Regarding continous publishing - that is a known problem with free and shared sites and one that cost me a few hours. Basically, when you are deploying by this mechanism and you specify corecelr, the entire runtime is re-installed from Nuget and that takes up nearly 1GB (the allowance for free and shared sites). Add a few NPM packages and you are over the limit and, hey presto, you can't deploy. #shanselman discussed it recently on one of his podcasts. It's not actually the runtime binaries that take up all the space, but because we are in build mode, all the documentation XML files are installed as well, because Nuget doesn't know you are not in a development environment, and they are huge.
Right now, the simplest answer if you want to use continuous publishing on a free or shared site is to also include the full runtime in your project.json and set your global.json to use the full CLR instead of the coreclr. Just very frustrating.

I was having the same problem. This answer solved the issue.
When creating a new project with the asp.net core template the global.json file was part of my API project, but it was also referenced in the Solution Items folder. When published to an Azure API app, two global.json files were deployed:
In the /approot/global.json
In the /approot/src/MyAPI/global.json
I moved the global.json file out of the project folder to the solution root, and re-added a reference back into the Solution Items folder.
When deployed only the /approot/global.json file was then deployed, resolving the issue.

IIS 7.5 Tracing area "...." is not recognized - HTTP Error 500.0 - Internal Server Error

Everything was working fine and all of a sudden I started getting the following error for all my web projects and websites. One thing is for sure that this is IIS issue since the compiler is not even reach the code.
Error Message:
HTTP Error 500.0 - Internal Server Error
Tracing area "Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module,FastCGI,WebSocket,Rewrite,RequestRouting,iisnode" is not recognized
I've already tried following things one by one but no luck:
Re-install Tracing - 'Turn Windows features on or off',
Re-install IIS,
aspnet_regiis -i (also tried with -u),
Removed ISAPI .DLL
Windows Features:
I'm using Visual Studio 2013 to build a web project (asp.net C#).
I would really appreciate any help/information on this Issue.

I removed below tag from applicationhost.config file located under C:\Users\Sanket\My Documents\IISExpress\config path on windows 7 machine.
<add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module,FastCGI,WebSocket,Rewrite,RequestRouting,iisnode" verbosity="Verbose" />
See if this helps.

From Richard Marr's Blog here, following solutions are listed and second solution worked for me.
Using Programs and Features find the Extension that is missing trace areas, right click select REPAIR.
Manually add the trace areas to the Applicationhost.config file as shown below. Remember to add in the "WWW Server" xml Node.

Sanket's suggestion works, but for me what was missing was
<add name="RequestRouting" value="2048" />
a few lines above in the applicationhost.config file, where all areas are defined. Adding this fixed it.
Btw. using VS2015 also fixes the problem without editing the .config file.

Do you have all modules listed in error message installed? You can download extensions here: (link for rewrite module) http://www.iis.net/downloads/microsoft/url-rewrite

To add to Sanket's solution:
In case you are not using IIS Express, in
C:\Inetpub\Wwwroot\Web.Config
Delete the line with:
"Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module,FastCGI,WebSocket,Rewrite,RequestRouting,iisnode" verbosity="Verbose"

In my case I was getting the error in IIS (NOT IIS express). I answered this question here:
https://stackoverflow.com/a/51717759/2817987