Month: April 2017

How to troubleshoot: “An error occurred while starting the application” in ASP.NET Core on IIS

Scott Sauber43 Comments

The Problem

If you’ve ever seen this message when hitting your ASP.NET Core app:

“An error occurred while starting the application.  .NET Framework <version number> | Microsoft.AspNetCore.Hosting version <version number> | Microsoft Windows <version number>”

It looks a little something like this:

2017-04-07_15-20-55

 

What Happened?

It basically means something really bad happened with your app.  Some things that might have gone wrong:

  1. You might not have the correct .NET Core version installed on the server.
  2. You might be missing DLL’s
  3. Something went wrong in your Program.cs or Startup.cs before any exception handling kicked in

 

Event Viewer (probably) won’t show you anything

If you’re running on Windows and behind IIS, you might immediately go to the Event Viewer to see what happened based on your previous ASP.NET knowledge.  You’ll notice that the error is not there.  This is because Event Logging must be wired up explicitly and you’ll need to use the Microsoft.Extensions.Logging.EventLog package, and depending on the error, you might not have a chance to even catch it to log to the Event Viewer.

 

How to figure what happened (if running on IIS)

Instead of the Event Viewer, if you’re running behind IIS, we can log the request out to a file.  To do that:

  1. Open your web.config
  2. Change stdoutLogEnabled=true
  3. Create a logs folder
    1. Unfortunately, the AspNetCoreModule doesn’t create the folder for you by default
      1. If you forget to create the logs folder, an error will be logged to the Event Viewer that says: Warning: Could not create stdoutLogFile \\?\YourPath\logs\stdout_timestamp.log, ErrorCode = -2147024893.
    2. The “stdout” part of  the value “.\logs\stdout” actually references the filename not the folder.  Which is a bit confusing.
  4. Run your request again, then open the \logs\stdout_*.log file


Note – you will want to turn this off after you’re done troubleshooting, as it is a performance hit.

So your web.config’s aspNetCore element should look something like this

 <aspNetCore processPath=”.\YourProjectName.exe” stdoutLogEnabled=”true” stdoutLogFile=”.\logs\stdout” />

 

Doing this will log all the requests out to this file and when the exception occurs, it will give you the full stack trace of what happened in the \logs\stdout_*.log file

2017-04-07_15-35-45.png

 

2017-04-07_15-42-40.png

 

 

Hope this helps.  This happened to me a friend of mine.  A friend.  Yep.  Definitely not me.  My apps would never bomb.

Error Upgrading to Visual Studio 2017 15.1 Unable to do .NET Core/ASP.NET Core Development

Scott Sauber2 Comments

UPDATE: Looks like this was fixed on 4/10/17 in the Update 1 26403.03 Release Notes.  I would just upgrade to get the fix.

I got an error when upgrading to Visual Studio 2017 15.1 where it wouldn’t install the .NET Core workload.  This prevented me from opening ASP.NET Core projects.

The product failed to install the listed workloads and components due to one or more package failures.

Incomplete workloads .NET Core cross-platform development (Microsoft.VisualStudio.Workload.NetCoreTools,version=15.0.26323.1) ASP.NET and web development (Microsoft.VisualStudio.Workload.NetWeb,version=15.0.26323.1)

Incomplete components .NET Core 1.0 – 1.1 development tools (Microsoft.NetCore.ComponentGroup.Web,version=15.0.26208.0) .NET Core 1.0.1 development tools (Microsoft.Net.Core.Component.SDK,version=15.0.26208.0) Container development tools (Microsoft.VisualStudio.Component.DockerTools,version=15.0.26323.1)

You can search for solutions using the information below, modify your selections for the above workloads and components and retry the installation, or remove the product from your machine.

Following is a collection of individual package failures that led to the incomplete workloads and components above. To search for existing reports of these specific problems, please copy and paste the URL from each package failure into a web browser. If the issue has already been reported, you can find solutions or workarounds there. If the issue has not been reported, you can create a new issue where other people will be able to find solutions or workarounds.

Package ‘Microsoft.Net.Core.SDK,version=15.0.26323.1,chip=x64’ failed to install. Search URL: https://aka.ms/VSSetupErrorReports?q=PackageId=Microsoft.Net.Core.SDK;PackageAction=Install;ReturnCode=1638 Impacted workloads .NET Core cross-platform development (Microsoft.VisualStudio.Workload.NetCoreTools,version=15.0.26323.1) ASP.NET and web development (Microsoft.VisualStudio.Workload.NetWeb,version=15.0.26323.1) Impacted components .NET Core 1.0 – 1.1 development tools (Microsoft.NetCore.ComponentGroup.Web,version=15.0.26208.0) .NET Core 1.0.1 development tools (Microsoft.Net.Core.Component.SDK,version=15.0.26208.0) Container development tools (Microsoft.VisualStudio.Component.DockerTools,version=15.0.26323.1) Log C:\Users\scotts\AppData\Local\Temp\dd_setup_20170406164409_003_Microsoft.Net.Core.SDK.log Details Command executed: “C:\ProgramData\Microsoft\VisualStudio\Packages\Microsoft.Net.Core.SDK,version=15.0.26323.1,chip=x64\dotnet-dev-win-x64.1.0.2.exe” “C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise” /log “C:\Users\scotts\AppData\Local\Temp\dd_setup_20170406164409_003_Microsoft.Net.Core.SDK.log” /quiet /norestart Return code: 1638 Return code details: Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel.

 

I ended up fixing this by:

  1. Repairing Microsoft Visual C++ 2017 x64, then rebooting.
  2. Repairing Microsoft Visual C++ 2017 x86, then rebooting.
  3. Installing the missing features by opening up a ASP.NET Core project and right-clicking and clicking “Install Missing Features.”  I’m sure you can get there by “modifying” the VS 2017 installation as well.

 

Hope this helps someone.

Quick xUnit Test Tip – Use xunit.methodDisplay to Clean Up Your Test Results

Scott SauberLeave a comment

I recently discovered an xUnit configuration value that was super helpful, so thought I’d write up a quick blog post.

Out of the box, xUnit results look like this in Visual Studio Test Explorer:

xUnitBefore

 

About half of that is noise, specifically the namespace (xUnitDemo) and the class name (DrivingServiceIsValidAgeToDrive).  The namespace isn’t really relevant to the test, and the class name is already available as the parent node above all the tests.

Solution

A simple change to your app.config will make this much easier to read.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
    <add key="xunit.methodDisplay" value="method"/>
  </appSettings>
</configuration>

 

Now when we run we get this:

xUnitAfter

Much cleaner.

 

As an aside.  I prefer the naming convention of:

  • Test Class Name: <ClassYou’reTesting><MethodYou’reTesting>
    • Example above, DrivingService is the class and IsValidAgeToDrive is the method
  • Test Method Name: Does<Something>_Given<Scenario>
    • Example above, DoesReturnTrue_GivenAgeIs16OrOlder

 

I’ve found this helps make it crystal clear what you’re testing.  As a bonus, it makes it fairly easy to show the names to a BA/Stakeholder to make sure you’re covering all their scenarios.

Adding Global Error Handling and Logging in ASP.NET Core with IExceptionHandlerPathFeature

Scott Sauber11 Comments

tldr;

In ASP.NET Core you can hook up a route to be your global exception handler.  Simply add the ExceptionHandler middleware to your Startup.cs Configure method:


// when an exception occurs, route to /Home/Error
app.UseExceptionHandler("/Home/Error");

view raw

Startup.cs

hosted with ❤ by GitHub

In your HomeController’s Error action, add this code to get the exception that was raised, as well as the route that caused the exception, and then you can do something with it (log to a database, send an email/text/fax/carrier pidgeon).


using System;
using Microsoft.AspNetCore.Diagnostics;
using Microsoft.AspNetCore.Mvc;
namespace GlobalExceptionHandling.Controllers
{
public class HomeController : Controller
{
public IActionResult Error()
{
// Get the details of the exception that occurred
var exceptionFeature = HttpContext.Features.Get<IExceptionHandlerPathFeature>();
if (exceptionFeature != null)
{
// Get which route the exception occurred at
string routeWhereExceptionOccurred = exceptionFeature.Path;
// Get the exception that occurred
Exception exceptionThatOccurred = exceptionFeature.Error;
// TODO: Do something with the exception
// Log it with Serilog?
// Send an e-mail, text, fax, or carrier pidgeon? Maybe all of the above?
// Whatever you do, be careful to catch any exceptions, otherwise you'll end up with a blank page and throwing a 500
}
return View();
}
}
}

view raw

HomeController.cs

hosted with ❤ by GitHub

You can checkout this GitHub commit if you’d prefer to see it that way.

 

The start of the non-tldr;

No ELMAH in ASP.NET Core… yet

In pre-Core versions of ASP.NET, ELMAH was a popular library for doing Global Exception Handling.  When unhandled exceptions occurred, it let you do things like log them to a database, send an e-mail, etc. automagically.  Unfortunately, ELMAH is not ported to ASP.NET Core yet, so this led me to look at what other options were out there.

You could use one of the many of the Cloud providers for this like Application Insights, elmah.io (unaffiliated with the ELMAH project) or Exceptionless, but what if your company requires you to stay on-prem?  You can use Exception Filters, but those have some limitations, and I found a simpler way (arguably) that I didn’t find a blog post on, so I thought I’d write one up.

 

Step 1 – Hook up the ExceptionHandler middleware

If you’ve done much with ASP.NET Core, this will look very familiar to you.  First you need to hook up the ExceptionHandler middleware by adding this line to the Configure method of your Startup.cs:


// when an exception occurs, route to /Home/Error
app.UseExceptionHandler("/Home/Error");

view raw

Startup.cs

hosted with ❤ by GitHub

What that does is anytime an uncaught exception happens, it will send the request to the route listening on the path you  specified.  In the example above (and the default in the templates), that’s the Error Action on the Home Controller, obviously you can just change that to whatever you want.

Often, you’ll only want to use the Exception Handler in non-development environments, and instead use the DeveloperExceptionPage in Development, which is the new YSOD that gives you a stack trace and other good information.

A sample Configure method showing this is below:


public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
// other code removed for brevity
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
// when an exception occurs, route to /Home/Error
app.UseExceptionHandler("/Home/Error");
}
// other code removed for brevity
}

view raw

Startup.cs

hosted with ❤ by GitHub

 

Step 2 – Use IExceptionHandlerPathFeature to get the exception and the Path

Make sure you have the Microsoft.AspNetCore.Diagnostics NuGet package in your .csproj, or if you have the Microsoft.AspNetCore meta-package, then that contains the Microsoft.AspNetCore.Diagnostics package, so you’re all set.

In the action of the controller you’re listening on (in the above case, the Error action on the Home Controller).  Add the following code to your Error action.


using System;
using Microsoft.AspNetCore.Diagnostics;
using Microsoft.AspNetCore.Mvc;
namespace GlobalExceptionHandling.Controllers
{
public class HomeController : Controller
{
public IActionResult Error()
{
// Get the details of the exception that occurred
var exceptionFeature = HttpContext.Features.Get<IExceptionHandlerPathFeature>();
if (exceptionFeature != null)
{
// Get which route the exception occurred at
string routeWhereExceptionOccurred = exceptionFeature.Path;
// Get the exception that occurred
Exception exceptionThatOccurred = exceptionFeature.Error;
// TODO: Do something with the exception
// Log it with Serilog?
// Send an e-mail, text, fax, or carrier pidgeon? Maybe all of the above?
// Whatever you do, be careful to catch any exceptions, otherwise you'll end up with a blank page and throwing a 500
}
return View();
}
}
}

view raw

HomeController.cs

hosted with ❤ by GitHub

Breaking the code down

The code is pretty straight forward, but let’s break it down.  When an exception occurs, an IExceptionHandlerPathFeature is set.  This contains two properties: 1) the Path of the route at which the exception occurred (such as /Home/Index), and 2) the Exception that occurred under the Error property.  After that, you can do whatever you want with this information such as log it to a database, send an e-mail or trigger a carrier pidgeon (I believe the CarrierPidgeon API is coming back in .NET Standard 2.0).

If you want to see the code that makes IExceptionHandlerPathFeature work, you can view go to GitHub here and see the code where they set the Path in the ExceptionHandler middleware that we rigged up in our Startup class.

 

Make sure you get the right Feature

Be careful to make sure you get an IExceptionHandlerPathFeature with the Path in the name.  There is also a IExceptionHandlerFeature without Path in the name that does not have the Path of where the exception occurred.  Obviously, it’s pretty useful to know the source route of where the exception happened.

 

Make sure you catch any Exceptions in your Exception Handler Action

Also be careful and make sure to catch any exceptions in your Exception Handler Action.  Causing a second exception in your exception handler action will cause the entire middleware to stop and you’ll end up with a blank page and a 500 status code.  A scenario where this could happen is if you’re logging the exception to a database, but your database is down causing an exception.

 

Microsoft.AspNetCore.Diagnostics.Elm

Microsoft provides a package called ELM (Error Logging Middleware) that has some similar features to what ELMAH did.  One of the main features ELM has is it allows you to see events on a web page that aggregates those events.  You can read more about that here.  However, there doesn’t seem to be any intent to extend ELM to do things like report to a database or send e-mails, based on this response from Eilon of the ASP.NET team here, and it is non-persistent through app restarts.  In my scenarios, we don’t have a ton of use for this, as we prefer to be able to look and query for logs in a database, but I thought I’d mention it in case it is useful for your scenarios.

 

Additionally – AppDomains Coming Back in .NET Standard 2.0

If you’re using .NET Core (and not full framework), AppDomains are coming back in .NET Standard 2.0 to help with global exception handling, as described by Damian Edwards in the ASP.NET Community Standup here: https://youtu.be/_3y0QsXj2e4?t=31m17s 

 

Don’t like using IExceptionHandlerPathFeature in your Controller action?

That’s ok.  There’s another way to achieve this same thing using raw middleware, even bypassing IExceptionHandlerPathFeature completely, but I’ll save that for a followup blog post, as this is approaching 1000 words.

Thanks for reading!