appsettings.json file not found for .NET Core app hosted in Windows Service or InProcess IIS

[lspangler584]

Description
When using InProcess IIS hosting or Windows Service, the Agent looks for the appsettings.json using GetCurrentDirectory(). For InProcess IIS or a Windows Service, GetCurrentDirectory() returns the path of the IIS app pool process or - in the case of Windows Service - C:\Windows\system32\), not the path of the application.
This is a known issue in AspNetCore.

This Issue is to change the Agent to use a different way to get to the appsettings.json file.

One alternative is suggested in the AspNetCore Issue.
Another alternative may be to use the AppContext.BaseDirectory property instead of GetCurrentDirectory().

Expected Behavior
The Agent should find and use appsettings.json if it is located in the current working directory of the application.

Steps to Reproduce

• Create a .NET Core application to be hosted in a Windows Service or InProcess IIS.
• Install the Agent.
• In appsettings.json, set configuration for app name:

  {
      "NewRelic.AppName": "Descriptive Name"
  }
  

• Run the application with the Agent engaged.
• Verify via agent log or New Relic UI that the application name is not what was specified in appsettings.json.

Your Environment
.NET Core application, hosted in InProcess IIS or Windows Service.

Additional context
Workarounds:

1. IIS apps can be set to run out of process via the web.config which allows the agent to find the correct appsettings.json
   <aspNetCore processPath="dotnet" arguments=".\MVCcore.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="OutOfProcess" />
2. Use app-local newrelic.config file for supported Agent configuration instead of appsettings.json.

Internal NR only: ref1 ref2 ref3

Note about development environment
N/A

[lspangler584]

Related issue here.

[vuqtran88]

Related issue here.

Just want to clarify, these 2 issues result in the same agent behavior, but the cause of them are different. #9 is due to agent reading the incorrect environment variable as opposed to the usage of GetCurrentDirectory returns an unexpected path.

[nr-ahemsath]

A few notes on findings during the process of reproducing (or failing to reproduce) this issue, and the subsequent fix:

1. I was never able to repro the issue in an IIS-hosted (in-process) scenario. I attempted this using ASP.NET Core MVC template applications created in Visual Studio 16.8.2, first targeting .NET Core/ASP.NET Core version 3.1 and then version 2.2. Even though there are forum posts describing users of ASP.NET Core 2.2 running into this problem, I wasn't able to repro the issue in 2.2 However: before starting this process, I needed to install the "ASP.NET Core module for IIS", as described in these instructions from MSFT: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/aspnet-core-module?view=aspnetcore-5.0. I was using version 15.0.20300.0 of this module for all IIS-hosted test scenarios. If MSFT's fix for this issue is in the module, it would explain why I wasn't ever able to repro the problem in an IIS-hosted scenario.
2. I was eventually able to repro the issue with a .NET Core 2.2 console app hosted as a Windows service, following these instructions: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/windows-service?view=aspnetcore-5.0&tabs=visual-studio Note that near the top of those instructions, there is a link to a reference sample application. In this sample app, the following code exists in the Main method of Program.cs:

if (isService)
{
   var pathToExe = Process.GetCurrentProcess().MainModule.FileName;
   var pathToContentRoot = Path.GetDirectoryName(pathToExe);
   Directory.SetCurrentDirectory(pathToContentRoot);
}

I was only able to repo the issue if I commented out this code. This demonstrates a workaround that could be used for customers unable to update to the latest version of our agent, as long as they are still able to make changes to their application code.

The linked PR to fix this issue uses a different method for obtaining the application base directory that uses AppDomain.CurrentDomain.BaseDirectory, as web searches indicated that this is the most robust/reliable method for getting the location of a running .NET Core application's published files on disk, which is where appsettings{.environment}.json should be.