In-Process hosting Directory.GetCurrentDirectory() location

[epignosisx]

Hi folks. I was reading the documentation on the new IIS in-process hosting option and kind of disappointing about this point:

Directory.GetCurrentDirectory() returns the worker directory of the process started by IIS rather than the application directory (for example, C:\Windows\System32\inetsrv for w3wp.exe).

Source: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/aspnet-core-module?view=aspnetcore-2.2

Any code that was expecting the location to point to the application folder will be up for a big surprise. This might also be a problem for libraries relying on the current behavior.

This difference is going to trip up developers trying to evaluate the new model. Even worse if they develop in one hosting model but deploy to another another hosting model.

The w3wp process path feels very useless in my mind. I can’t think of a use case where I would care about it.

[jkotalik]

Sorry for not getting to this sooner, holidays in the states.

@epignosisx , appreciate the feedback. We are aware of this issue and attempted a fix (see: aspnet/IISIntegration#1437), however making this fix is risky.

To make Directory.GetCurrentDirectory() work, we need to set the current working for the entire w3wp.exe process to your application directory. After changing the current directory, if IIS tries to load a module lazily or another IIS module relies on the current working directory being C:\Windows\System32\inetsrv, that will start failing, which may or may not be recoverable.

The way we host ANCM In-Process is similar to System.Web (inside of the w3wp process). System.Web had Directory.GetCurrentDirectory() as C:\Windows\System32\inetsrv too.

As a work around, we set the ContentRoot to be the application directory in Configuration. Anywhere that you can resolve IConfiguration, you can use IConfiguration[HostDefaults.ContentRootKey] to obtain the application directory.

If this issue affects many users, we may consider investigating more into resolutions.

cc @muratg @shirhatti

[shirhatti]

As @jkotalik alluded to, we will not revisit this unless it proves to be a pit of failure.

This is no different from dotnet run --project /path/to/project from a different directory OR no different from System.Web like Justin mentioned.

[epignosisx]

I definitely did not expect this to be such a hard issue to maintain interoperability with IIS. However, what would happen if as the first line of my Program.cs, this is done:

public class Program
{
    public static int Main(string[] args)
    {
        Directory.SetCurrentDirectory(...);
    }
}

Would this work in the context of my app without interfering with IIS? Because, if that’s the case, I’m fine with that and I’m guessing a lot of users will be fine with that too, that is, they do not care about deep integration with IOS other than the basic hosting.

Secondly, if I need to get real application directory, how can I do it when IConfiguration[HostDefaults.ContentRootKey] is not available? For example, we are following something similar to pattern to set up our logging:

https://github.com/serilog/serilog-aspnetcore/blob/a2c1d9c437f524b1488e27d40c1b789322b9889b/samples/SimpleWebSample/Program.cs#L1-L54

namespace SimpleWebSample
{
    public class Program
    {
        public static IConfiguration Configuration { get; } = new ConfigurationBuilder()
            .SetBasePath(Directory.GetCurrentDirectory())  // <----- How do we make this work?
            .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
            .AddJsonFile($"appsettings.{Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") ?? "Production"}.json", optional: true)
            .AddEnvironmentVariables()
            .Build();


        public static int Main(string[] args)
        {


            Log.Logger = new LoggerConfiguration()
                .ReadFrom.Configuration(Configuration)
                .Enrich.FromLogContext()
                .WriteTo.Console()
                .CreateLogger();


            try
            {
                Log.Information("Getting the motors running...");


                BuildWebHost(args).Run();


                return 0;
            }
            catch (Exception ex)
            {
                Log.Fatal(ex, "Host terminated unexpectedly");
                return 1;
            }
            finally
            {
                Log.CloseAndFlush();
            }
        }


        public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                   .UseStartup<Startup>()
                   .UseConfiguration(Configuration)
                   .UseSerilog()
                   .Build();
    }
}

Notice in the creation of the configuration this line: SetBasePath(Directory.GetCurrentDirectory()), how would this work with in-process hosting before any WebHost has been created?

[epignosisx]

A top level API as simple as this one would be needed:

https://docs.microsoft.com/en-us/dotnet/api/system.web.hosting.hostingenvironment.applicationphysicalpath?view=netframework-4.7.2#System_Web_Hosting_HostingEnvironment_ApplicationPhysicalPath

To enable the example above.

[Tratcher]

We don't do static APIs like that anymore.

[epignosisx]

@Tratcher how can the sample code above would work then?

[Tratcher]

Re-opening for @shirhatti to address.

[shirhatti]

• We'll look into exposing ContentRoot via an environment variable into the 2.2.x Patch train.
• For 3.0, we'll either have to expose it via a static 😢 or see if you we can get coreclr to allow us to set AppDomain.CurrentDomain.BaseDirectory ahead of time

[shirhatti]

The only workaround at the moment, is to Pinvoke directly and read the applicationPath yourself directly from iis config. See https://github.com/aspnet/AspNetCore/blob/master/src/IISIntegration/src/Microsoft.AspNetCore.Server.IIS/WebHostBuilderIISExtensions.cs#L35-L38