50

I've been developing an ASP.NET Core web app, based largely on the MVC template provided in Visual Studio 2017 RC2. It runs just fine in local debug mode, but when I try to publish it to an Azure hosted web app, I get this error:

enter image description here

An error occurred while starting the application.

.NET Core X86 v4.1.1.0 | Microsoft.AspNetCore.Hosting version 1.1.0-rtm-22752 | Microsoft Windows 6.2.9200

I've tried setting stdoutLogEnabled="true" in the web.config file, but it seems to have no effect, the error is the same.

Update:

With some help I managed to retrieve the log, and it says:

Application startup exception: System.TypeLoadException: Could not load type 'System.IO.File' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.    
   at Microsoft.Extensions.DependencyModel.FileWrapper.OpenRead(String path)
   at Microsoft.Extensions.DependencyModel.DependencyContextLoader.LoadEntryAssemblyContext(IDependencyContextReader reader)
   at Microsoft.Extensions.DependencyModel.DependencyContextLoader.Load(Assembly assembly)    
   at Microsoft.Extensions.DependencyModel.DependencyContext.Load(Assembly assembly)    
   at Microsoft.AspNetCore.Mvc.Internal.DefaultAssemblyPartDiscoveryProvider.DiscoverAssemblyParts(String entryPointAssemblyName)    
   at Microsoft.Extensions.DependencyInjection.MvcCoreServiceCollectionExtensions.GetApplicationPartManager(IServiceCollection services)    
   at Microsoft.Extensions.DependencyInjection.MvcCoreServiceCollectionExtensions.AddMvcCore(IServiceCollection services)    
   at Microsoft.Extensions.DependencyInjection.MvcServiceCollectionExtensions.AddMvc(IServiceCollection services)    
   at Bla.Api.Startup.ConfigureServices(IServiceCollection services) in C:\Users\user\Source\Workspaces\Bla\Bla.Api\src\Bla.Api\Startup.cs:line 73
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.AspNetCore.Hosting.ConventionBasedStartup.ConfigureServices(IServiceCollection services)
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.EnsureApplicationServices()
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.BuildApplication()

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

The line of code it refers to at line 73 is:

services.AddMvc();

Update:

My global.json file looks like this (where Bla.Api is the name of the project, and the file sits in the solution root folder).

{
  "projects": [ "Bla.Api" ],
  "sdk": {
    "version": "1.1.0"
  }
}
derf26
  • 862
  • 1
  • 7
  • 16
  • It's possible that you're running a different version of the .NET SDK in Azure than you are running locally. Consider adding a global.json file to your project that pins the SDK at a specific version. https://learn.microsoft.com/en-us/dotnet/articles/core/tools/global-json#sdk – Shaun Luttin Jan 29 '17 at 20:27
  • Thanks for the tip Shaun! My template didn't come with a global.json file, so I created one and put it in the solution's root folder. I tried a couple of different version numbers for the SDK (1.1.0 and 1.1.0-rtm-22752) but I don't think it had any effect. Nothing happened. Maybe I'm missing something? – derf26 Jan 29 '17 at 20:57
  • Also as another update, I patiently re-created what I did yesterday in a brand new VS 2017 RC3 template for 1.1.0 (which looks different from before, they've removed the src folder and it looks much cleaner). I got it to the same debug working state as before but on publish, once again it doesn't work. I do believe Azure is missing something but I don't know how to get it there. – derf26 Jan 29 '17 at 20:58
  • What SDK version are you running locally. Try `dotnet --version` to find out from the command line. Then use that version in your global.json and paste your global.json file into your question. – Shaun Luttin Jan 29 '17 at 21:03
  • Looks like it's version 1.1.0, I've pasted into question my global.json. – derf26 Jan 29 '17 at 21:20
  • To properly update your `global.json`, you need to add the full version number. For instance, on my machine `dotnet --version` outputs `1.0.0-rc3-004517` and my `global.json` `version` property includes that entire version number. – Shaun Luttin Jan 29 '17 at 21:41
  • For me, the full version is 1.1.0, have a look at my screenshot: http://imgur.com/a/b1qAz – derf26 Jan 29 '17 at 22:08
  • Is that from running `dotnet --version` from the command line? What operating system are you running locally? – Shaun Luttin Jan 29 '17 at 23:31
  • Yeah that's running it from the command line. I'm on Windows 10 home. – derf26 Jan 30 '17 at 08:07
  • Have to tried to add runtime? `"runtimes": { "win10-x86": {}, "win10-x64": {}, "win7-x64": {},"win7-x86": {} }` – Tom Sun - MSFT Jan 30 '17 at 09:29
  • Hi Tom Sun, I tried adding what you suggested in the global.json, to no avail :( I even went as far as deleting the web app in Azure and creating a brand new one from scratch, in case there were for some reason old .dlls sitting around, and I'm still getting the same error... – derf26 Jan 30 '17 at 17:46
  • 1
    Wait, I think it worked! Re-creating a new Azure Web App did the trick. The new error was that I had an environment variable missing (as it was a new web app and I hadn't created it yet). After I set it up, it was fine. So my assumption about the previous web app being somehow messed up were correct I guess... Anyway, thanks for everyone's help! Woo! – derf26 Jan 30 '17 at 18:09
  • 1
    @derf26 I encourage you to spend 20-minutes or so typing up your own answers as a post mortem. It would be an interesting read for me, to know exactly what went wrong. – Shaun Luttin Jan 30 '17 at 18:11
  • 2
    I've written up a brief summary with what did and didn't work, and what I learned :) Thanks again for all your help. I'm so happy it's finally working :D – derf26 Jan 30 '17 at 18:15

10 Answers10

132

Since many different problems can cause this error page, I can strongly recommend the following in order to determine the root cause quickly and easily, without wrestling Azure (or any server/platform for that matter) to get logs.

You can enable extremely helpful developer friendly error messages at startup by setting the .UseSetting("detailedErrors", "true") and .CaptureStartupErrors(true) actions in your Program.cs file.

For ASP.NET Core 1.x

public static void Main(string[] args)
{
  var host = new WebHostBuilder()
      .UseKestrel()
      .UseContentRoot(Directory.GetCurrentDirectory())
      .UseSetting("detailedErrors", "true")
      .UseIISIntegration()
      .UseStartup<Startup>()
      .CaptureStartupErrors(true)
      .Build();

  host.Run();
}

(2018/07) Update for ASP.NET Core 2.1

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

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .CaptureStartupErrors(true)
            .UseSetting("detailedErrors", "true")
            .UseStartup<Startup>()
            .Build();
}
  • These settings should be removed as soon as your troubleshooting is complete so as not to expose your application to malicious attacks.
Steve Land
  • 4,852
  • 2
  • 17
  • 36
  • 2
    This really helped me to find out where my problem was! Thank you so much! – Farlop Jun 02 '17 at 09:33
  • Holy cow.. I never knew about that! It is great but is there any way to set it per Environment? :D – Piotr Kula Nov 02 '17 at 15:43
  • 1
    @ppumkin yes - just capture settings from your relevant config/environment and use those when calling `.UseSetting("detailedErrors", [env-setting])` and `.CaptureStartupErrors([env-setting])` See https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration – Steve Land Nov 09 '17 at 16:07
  • @Steveland83 How exactly are you supposed to capture the environment? I looked at the link but not seeing exactly which way to go about this. Should I be doing `var environment = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT");` – Met-u Feb 12 '18 at 08:21
  • 2
    @Met-u Yes, exactly that. Dont forget that you will need to manually set these variables for each environment either in your `Web.config` (see https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/aspnet-core-module#setting-environment-variables ) or manually on the server as per: https://stackoverflow.com/a/41551429/7840778 – Steve Land Feb 12 '18 at 09:57
  • This helped me figure out my issue, thank you! For me, the actual issue was a connection string with a missing escape of a `\` character.. – Fredrik Lundin Apr 13 '18 at 11:00
8

Connect via an sftp client and delete everything in the site/wwwroot folder manually. Republish

I have had nothing but problems since I migrated an application I have hosted on Azure to .net core from MVC 4.

At one point a few weeks ago I was unable to get a project to run after a successful publish. I even tried twice to delete the entire App Service profile and recreate it with the same name. However when I appended a '2' to the App Service name (to create a never before used app service) publishing the exact same project with 0 changes worked perfectly. What exactly does a delete do if I can publish successfully to a new app service but not a deleted and recreated one? Remove Existing Files At Destination was checked in each publish, that didn't do anything either.

I had the same error today as pictured in the OP in my #2 site. It occurred after attempting to update a number of asp nuget packages and re-deploy. Really not wanting to have to move on to iteration myApp3 of my app service, I decided to use the FTP information provided in the azure overview page. I navigated to Site/wwwroot and deleted everything inside from the FTP client. I then published the application, and it worked. I can only conclude that the 'Delete' checkbox doesn't work properly.

Pete
  • 267
  • 3
  • 8
  • Thanks for the tip Pete, I'm hoping that if I ever have this issue again, I'll be able to do the same. Like you, I really don't want to be deleting and re-creating web apps! – derf26 Feb 06 '17 at 22:02
  • You can also do this via the developer console in azure. – rollsch Oct 24 '17 at 23:30
6

Thanks everyone for your suggestions. The only thing that worked in the end though is deleting that Azure web app that I couldn't publish to, and creating a brand new one. I guess maybe some of the .dlls from the previous runtime environment were still hanging around or not being updated... Whatever it was, re-creating it worked. Hopefully I don't get this error again though, because you can't really do this kind of stuff in production.

Making changes to the global.json file seemed to have no effect.

Creating an entirely new API from a template didn't help either, the issue was with the Azure Web App itself, as everything was running fine locally.

Another very helpful tip was to add logging (and the "logs" file in the root) as per the other answer. That at least pointed me in the right direction. Also checking your runtime with dotnet --version.

Again thanks for everyone's help!

derf26
  • 862
  • 1
  • 7
  • 16
5

I've got the same problem. Just not deployed at Azure, I'm using my local machine as server and host it in IIS.

An error occurred while starting the application.

.NET Core X64 v4.1.1.0    |   Microsoft.AspNetCore.Hosting version 1.1.1    |    Microsoft Windows 10.0.14393    |   Need help?

And this was solved by changing web.config.

First set stdoutLogEnabled = "true"

Then make sure stdoutLogFile=".\logs\stdout" /> this folder exists.

And then restart IIS, you can find the real problem in log file.

wtf512
  • 4,487
  • 9
  • 33
  • 55
  • In my case, the real problem was actually a bug with .NET Core not deploying correctly, not something I had done. Re-creating the entire Azure Web App was the only thing that fixed it, with my code never having been changed. But yes, generally that's good advice to figure out what's happening. – derf26 Mar 31 '17 at 11:13
  • I do this - no log file is created – niico May 29 '18 at 19:56
3

DELETE all existing dll from wwwroot/your_application_folder, then copy all of the publish output files&folders.

The problem occurs when the NUGETS update it self. If you don't clean the existing files under wwwroot/your_application_folder IIS gives the error above.

Fuat
  • 789
  • 9
  • 14
2

Clean and rebuild fixed everything.

1

Question is probably duplicated - please refer to ASP.NET Core hosting - 500 internal server error.


Quick answer:

You need to set: stdoutLogEnabled="true" and stdoutLogFile=".\logs\stdout". Also, you need to create logs folder manually.

Community
  • 1
  • 1
Lukasz Mk
  • 7,000
  • 2
  • 27
  • 41
  • Thanks for the tip! I've created the folder structure as per the linked answer, and it looks like a log is created, but I can't actually open it. See here: http://imgur.com/a/bvAD7 – derf26 Jan 28 '17 at 23:52
  • It turns out it's because that log file was still open by the application I guess... must have had a handle on it. Re-deploying created a new log file and released the old one, I've updated my question with what the log says. – derf26 Jan 28 '17 at 23:59
0

In my case, it was because I was trying to publish user secrets for use with Fabook OAuth. I know that's a very situational specific answer, but OAuth seems pretty common these day. User Secrets, it turns out, are not meant to be published. Who knew.

So to test this I temporarily changed the following code in startup.cs. This data should be not hard coded as a part of best practice, as it would end up in clear text in source control.

Before

    app.UseFacebookAuthentication(new FacebookOptions()
    {
        AppId = Configuration["Authentication:Facebook:AppId"],
        AppSecret = Configuration["Authentication:Facebook:AppSecret"]
    });

After

    app.UseFacebookAuthentication(new FacebookOptions()
    {
        AppId = "0000000000000", // your value
        AppSecret = "0000000000000000000000000000000" // your value
    });

Then it worked.

Dave
  • 4,949
  • 6
  • 50
  • 73
0

In My case, that was because I was trying to get a some data in Startup, and dbcontext was not updated in production environment.

Changed my ConnectionString to Production and runned Update-Database, and problem solved.

mesut
  • 2,099
  • 3
  • 23
  • 35
0

In my case there was a directory named Resources that was missing in app directory.

Hamid Reza
  • 150
  • 1
  • 5