We have an in-house developed C# .NET application that we are trying to put in windows containers. The application was originally designed to run as a service but it seems to be that containers are better run as a process. So the devs have made some small changes and we can now run the application from the command line. It runs successfully on Win 10, 2012 R2, 2016, and 2019.
However, when trying to run the exact same application on a 2016 or 2019 container, we get the error message:
Cannot start service from the command line or a debugger. A Windows Service must first be installed (using installutil.exe) and then start with the ServerExplorer, Windows Services Administrative tool or the NET START command.
Why would running in a container change the way the application runs? There are no dependencies (other than .NET) for the application that are not included with the application.
I'm able to successfully install the application as a service in the container and start the service without errors. However trying to curl http://localhost in the container or outside the container fails even with the port is exposed via the -p 80:80 option from docker run.
I've seen previous versions of this application run successfully in a docker container as a process so I figure it has to be some caveat of C# but I'm not a dev and I'm getting a standard "it runs on the host, it must be a docker thing" answer from our devs.
It turns out the code had an if statement on Environment.UserInteractive which told it whether to behave as console or service. In Windows Docker containers, the Environment.UserInteractive always triggers as false for some reason which forced the application to service even when run as a console. We used an environment variable to override the if.
Worth noting that apparently in .NET Core, the variable always triggers as true which may be helpful given the way Linux apps are usually triggered.