I am developing a .NET Core 2.1 console application using dependency injection (Microsoft.Extensions.DependencyInjection). The code looks something like this:
class Program
{
static async Task Main(string[] args)
{
//...
var configuration = GetConfiguration();
var serviceProvider = ConfigureServices(configuration);
var importer = serviceProvider.GetRequiredService<DataImporter>();
var result = await importer.ImportCentersAndStores(fileName);
//...
}
private static IConfigurationRoot GetConfiguration()
{
return new ConfigurationBuilder()
.AddJsonFile("appsettings.json")
.Build();
}
private static ServiceProvider ConfigureServices(IConfigurationRoot configuration)
{
System.Text.Encoding.RegisterProvider(System.Text.CodePagesEncodingProvider.Instance);
return new ServiceCollection()
.AddLogging(builder =>
{
builder.AddConfiguration(configuration.GetSection("Logging"));
builder.AddConsole();
})
.AddOptions()
.AddAutoMapper()
.AddDatabase(configuration.GetConnectionString("Blah"))
.AddTransient<DataImporter>()
.BuildServiceProvider();
}
}
The DataImporter
class and the ImportCentersAndStores
method are nothing special - it does various stuff including reading an Excel file and does some logging. I don't think the nature of that code is relevant.
Now the problem is that whenever an exception is thrown inside the DataImporter
class, the stack trace has no frames with my code:
The debugging display looks like this:
This happens whether I catch the thrown exception or not. The above exception happens within a method in DataImporter
called from ImportCentersAndStores
. So there should be two frames of my code there.
There is no context for debugging. I cannot inspect variables or anything.
I have no idea what System.Private.CoreLib
is or why it hogs most of the call stack. I do not know if the problem is actually related to my use of DI.
Just My Code makes no difference. Exception settings are default. I cannot see any debugging options that should do this.
In case you wonder: I have included this in the project file to enable the async Main method:
<LangVersion>7.1</LangVersion>
Can anyone shed any light on this?
On the second screenshot: Exception helper (popup) -> View details -> Stack trace. This will be the correct stack trace at the time the exception was thrown before the async
sausage kicked in.
So - yes - this behavior is because of your async
stuff. Which honestly makes me curious why would you ever do anything async
in console application?