Runtime: Add Environment ApplicationDirectory

[eerhardt]

Background and Motivation

The path of the current application is often needed to load files in your application directory. For example, appSettings.json configuration files, or image files.

This API is needed more than before now that we support single-file publishing and assemblies do not have physical file paths anymore. See https://github.com/dotnet/designs/blob/master/accepted/2020/form-factors.md#single-file for details.

We have AppContext.BaseDirectory, but that API is documented as:

Gets the pathname of the base directory that the assembly resolver uses to probe for assemblies.

There are scenarios where AppContext.BaseDirectory doesn't return the directory where the application lives, see https://github.com/dotnet/runtime/issues/40828#issuecomment-676519769 for example - PublishSingleFile in 3.0. Since AppContext.BaseDirectory is defined this way, it makes it unusable for the above purposes.

Proposed API

```C#
namespace System
{
public partial class Environment
{
// Returns the directory path of the application.
public string? ApplicationDirectory { get; }
}
}

## Usage Examples

``` C#
string configurationFile = Path.Combine(Environment.ApplicationDirectory, "appSettings.json");

[umbarov]

Maybe a short version: AppDirectory? Like appSettings.json, System.AppContext System.AppDomain. For app consistency.

public string? AppDirectory { get; }

...
string configFile = Path.Combine(Environment.AppDirectory, "appSettings.json");

[mklement0]

I suspect that is the plan anyway, but just to spell it out (correct me, if I'm wrong):

The return value will be the _full, physical path_ - with symlinks, if any, resolved - of the directory in which the executable is located, so that, say, an executable /path/to/exe that is symlinked to /usr/bin/exe and invoked as such still reports /path/to.

[_Applies only to regular, application-specific executables - see next comment_]
(Expressed in terms of the upcoming Environment.ProcessPath property, which returns the executable's full, physical file path: Path.GetDirectoryName(Environment.ProcessPath)).

[eerhardt]

The return value will be the full, physical path - with symlinks, if any, resolved - of the directory in which the executable is located, so that, say, an executable /path/to/exe that is symlinked to /usr/bin/exe and invoked as such still reports /path/to.

I would assume all symlinks would be followed, yes.

(Expressed in terms of the upcoming Environment.ProcessPath property, which returns the executable's full, physical file path: Path.GetDirectoryName(Environment.ProcessPath).

No, this wouldn't be the case for all scenarios. One easy example is when you use dotnet.exe to load an application. dotnet.exe bin\Debug\net5.0\MyApp.dll. Your proposal would have Environment.ApplicationDirectory return the location of the dotnet.exe executable. But the intention is for this API to return the full path of where MyApp.dll is located.

Other scenarios where your above definition is incorrect could potentially be Mobile/Xamarin scenarios.

My thought is that the Environment.ApplicationDirectory is the full, physical file path to where the logical .NET "EntryPoint" assembly is located on disk. Even if the actual "EntryPoint" assembly is packaged in some sort of aggregate package - like it is in "single file" applications. If the "EntryPoint" assembly wasn't loaded from some physical file (for example Blazor WASM), then Environment.ApplicationDirectory returns null.