I have an ASP.NET web app (.NET Framework 4.7.2.) deployed to AWS/ECS and we noticed Application_Start was running not once, not twice, but three times! Maybe others are facing this problem.
We resolved 1 of the 2 extra restarts. The first happens because Microsoft's docker entrypoint ServiceMonitor's first course of action is to stop the w3svc service, alter the applicationHost.config (via appcmd.exe) to inject docker-level environment variables (the ones supplied via ENV directives in the docker file or via the docker run command line parameters) into the DefaultAppPool's environment variable section, and then restarts the service.
Ordinarily, that wouldn't be a problem, but if your applications are set to auto-start with preloadEnabled=true, then what happens is the service starts once, automatically, with the container, only for ServiceMonitor to come along and stop it, change settings, and restart it again. So the initial system-initiated run is doomed and shouldn't happen in the first place. It doesn't have all the expected environment variables, and it's really only running because the app is set to auto-start. We worked around that by setting the w3svc startup mode to 'Manual'. This prevents the initial doomed Application_Start run, so that, at least in a local docker container, we get just a single startup run of the application, initiated after ServiceMonitor has applied the right settings.
Things are a bit different in ECS. In addition to the extra startup run triggered by ServiceeMonitor, we also get another (3rd) run triggered by some other settings that are applied at runtime presumably by ECS environment. My main question is, does anyone know what these ECS-instigated settings changes might be? Is ECS applying environment variables somehow or making other changes to IIS by default? This is something that's occuring only in ECS that does not occur when the same docker image is run locally on docker desktop.
Whatever these settings changes are, they're particularly disruptive, because they don't trigger the normal overlapped-process recycling that spins up a new, separate process that's warmed up before replacing the old one. These settings changes trigger the kind of in-process recycling you'd get if you modified a web.config file, for example. I think this replaces the AppDomain in the already-running process. This is bad for us, because we're running SignalFx low-level tracing libraries that hook into the CLR, and it causes a sharing violation that crashes a process when the new AppDomain tries to load the domain-neutral assemblies with different permissions. All of these extra application start cycles not only causes extra load on the system as it's doing triple of everything (including cache hydration from databases, setting up Azure topic subscriptions, etc.), but it's also placing extra memory demands on the system which can lead to OutOfMemory exceptions, especially in docker where containers have a hard memory limit.
