EDIT: This was previously entitled "App Init behaviour different between IIS Restart and Application Initialisation". I have changed the title to expand the question out from IIS/Application Initialisation because the observed behaviour relates to AppDomain.CurrentDomain.GetAssemblies();
I am using the IIS Application Initialisation module to warm-up an asmx wed service.
I have implemented some warm-up code to ensure app application initialisation successfully JIT's my asmx service in Global.asax Application_Start event. This uses System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod() to iterate through all of the assemblies in the application (it also picks up all of the assembly dependencies) to ensure that the first call to the service is as fast as possible.
When I obeserve this behaviour utilising "net stop w3svc & net start w3svc" I can see (via logging) that ALL of the assemblies are JIT'ted and the first call to the service is fast as expected.
However, when the application pool is automatically recycled on its configured time schedule (03:00:00) the log shows only the directly referenced assemblies are JIT'ted, not the dependencies that also sit in the folder.
This is resulting in an unacceptable overhead on the first call to the service.
The App Init performs exactly as expected in all other respects but why does the IIS re-cycle of the Application Pool only JIT compile the directly referenced assemblies and not its dependencies?
Well the post mentioned in my comment above led me in the right direction and then I found the answer on this post: Difference between AppDomain.GetAssemblies and BuildManager.GetReferencedAssemblies
So my code was changed to var assemblies = BuildManager.GetReferencedAssemblies();
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With