C# .NET 8: How do I prevent a Windows service EXE from running when double-clicked?

You can implement this behavior yourself by checking whether the process is running interactively. In .NET 8 (as in earlier versions of .NET Core), there isn’t a built-in mechanism that mimics the .NET Framework error message for Windows services run interactively. Instead, you can add a short check in your Main method and exit early if the process is started from a user session.

Below is an example:

CSHARPCopied
using System;
using Microsoft.Extensions.Hosting;

public class Program
{
    public static void Main(string[] args)
    {
        // When run interactively (e.g. by double-clicking the EXE),
        // Environment.UserInteractive will be true.
        if (Environment.UserInteractive)
        {
            Console.Error.WriteLine("This application is registered as a Windows service and cannot be run directly.");
            return; // Or use Environment.Exit(1);
        }
        
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .UseWindowsService() // Integrates Windows service behaviors.
            .ConfigureServices((hostContext, services) =>
            {
                // Register your worker service here.
                services.AddHostedService<Worker>();
            });
}

How This Works

• Environment.UserInteractive: When a process is started as a service, this property is normally false. When double-clicked by a user (or run from a command prompt), it returns true.
• Conditional Check: If the environment is interactive, the application writes an error message and exits rather than starting the host.
• UseWindowsService(): This extension method on the host builder ensures that the host integrates with the Windows service lifecycle, but does not itself prevent interactive execution.

Using this pattern, you ensure that your Windows service only starts its worker logic when it is invoked by the Windows service control manager and not when a user accidentally launches the executable.

This approach gives you control over the startup behavior without any additional runtime overhead for production service scenarios.