Yes I realise that the .Net Core Apps are self-hosting Console Apps. The issue is the control of what runs them. If I was just to run the app from command line e.g." dotnet some.dll" then it would serve using Kestrel and there would be no problem.
With IIS when using reverse proxy, however, the running of the dll is handled by the AspNetCoreModule (which under the hood presumably runs the “dotnet some.dll” which I mentioned. It does not start the dll until it has a request that would be served by it.
Unfortunately if the service has a background task or a messaging pipeline that is not HTTP based, that will not occur.
Just an update on this, I think I may have found a combination of settings in IIS which cause it to instantiate the console app as soon as website running.
I did the following:
Added configuration to the web.config under the system.webserver section
Under Site Advanced Settings, I set Preload Enabled to TRUE</li?
In order to keep the service running:
Under Application Pool (specific to site) advanced settings set the idle timeout to 0 so the console app doesn't get killed
Under same area set always running to true
Under same area, set recycle interval to zero
After doing these 5 things, I could finally get my app initializing working (outputting of logs and reciing of udp/tcp connections) after running the website without requiring an http request.
It should be noted that there is an InProc mode that ASP.Net supports however, it was temporarily removed for 2.1 apparently.
