UseWindowsService() does not work on docker containers

[drakeaan]

Describe the bug

When creating a windows service of a .NET Core 3.0/3.1 project, the service does not start if it's running inside a container.

To Reproduce

Steps to reproduce the behavior:

1. Create an ASP.NET Core 3.0 Project
2. Implement the Hosting extension and add app.UseWindowsService()
3. Create a docker container (.NET Framework) and install the .net core runtime
4. Register the service and attempt to start it.

Expected behavior

The service should start.

Additional context

WindowsServiceHelpers checks if the SessionId == 0. In containers, the sessionid will never be 0.

return parent.SessionId == 0 && string.Equals("services", parent.ProcessName, StringComparison.OrdinalIgnoreCase);

[analogrelay]

Why are you running a Windows Service inside a Windows Container? That seems odd. Can you provide a runnable sample application (including Dockerfile) that reproduces the problem?

[drakeaan]

It's a legacy "lift-and-shift" and short-term we have to run the micro side-by-side with the legacy application. Long-term is to move them into separate containers.

I will do.

[analogrelay]

@DewaldS Have you been able to set up a runnable sample? (I realize the holidays may have gotten in the way ;)). Let us know if you have such a sample.

[drakeaan]

@anurse Yeah... Sorry about that. With the holidays it was a bit difficult.

Attached is a zip file with a very simple project and dockerfile. There is also a BuildContainer.ps1 to build and publish the project and create the docker image.

When you create the container and exec into it, you'll notice the service remains in "Starting" for the default 30s period. After that it goes into a "Stopped" state as the service doesn't start.

# For Testing
docker run -it repro2778:latest powershell

# In terminal inside container
Get-Service WindowsCore31AsService

Executing the exe manually, however, indicates that the exe does work.

Below is the extension code we used to work around the problem (we removed the IsWindowsService() check).

public static IHostBuilder UseWindowsServiceInContainer(this IHostBuilder hostBuilder)
{
    // Host.CreateDefaultBuilder uses CurrentDirectory for VS scenarios, but CurrentDirectory for services is c:\Windows\System32.
    hostBuilder.UseContentRoot(AppContext.BaseDirectory);
    hostBuilder.ConfigureLogging((hostingContext, logging) =>
    {
        logging.AddEventLog();
    })
    .ConfigureServices((hostContext, services) =>
    {
        services.AddSingleton<IHostLifetime, WindowsServiceLifetime>();
        services.Configure<EventLogSettings>(settings =>
        {
            if (string.IsNullOrEmpty(settings.SourceName))
            {
                settings.SourceName = hostContext.HostingEnvironment.ApplicationName;
            }
        });
    });

    return hostBuilder;
}

Regards

Repro2778.zip

[analogrelay]

Yeah... Sorry about that. With the holidays it was a bit difficult.

No problem! Totally understandable. We'll take a look now that things are ramping back up here after the holidays 😉.

[mk185147]

We have the same issue. One thing that I don't see noted in the issue is that it isn't specific to containers. The same problem will appear on any Windows Server Core as it doesn't support SessionId 0 isolation.

[BrennanConroy]

Triage: We need to figure out a better heuristic for this. We should also consider an override switch "I know I can use WindowsService"

Workaround for now is to copy the code the service adds

hostBuilder.UseContentRoot(AppContext.BaseDirectory);
hostBuilder.ConfigureLogging((hostingContext, logging) =>
{
    logging.AddEventLog();
})
.ConfigureServices((hostContext, services) =>
{
    services.AddSingleton<IHostLifetime, WindowsServiceLifetime>();
    services.Configure<EventLogSettings>(settings =>
    {
        if (string.IsNullOrEmpty(settings.SourceName))
        {
            settings.SourceName = hostContext.HostingEnvironment.ApplicationName;
        }
    });
    services.Configure(configure);
});

[matt-psaltis]

Hit this on .net 5 today. Lost another 5 hours thinking its me and the way I'm building the services. Thank you to those who helped identify this issue and the fix does still work on .net 5.

Please fix!

[eerhardt]

Closing as a duplicate of #52416. That issue has the suggested solution, so using that one going forward.