My packaging standards usually involve scripted installs, both a pre-monitor script and another for the application installation.
The pre-monitor script will install application dependencies and then perform a flush of the NGEN queues to ensure that ngen compilation for dependencies (or OS crap in general) is not accidentally caught in the monitoring.
In the portion of the Packaging Tool where existing windows services that are best practice to stop/disable are detected, it would make sense to also flush the ngen queues.
On Win 10 there are up to two ngen queues to worry about, both x86 and x64 (C:\Windows\Microsoft.Net\Framework[64]\v4.0.*\ngen.exe). The queues can be queried and if needed flushed using ngen.exe EXECUTEQUEUEDITEMS.
Bonus points if you also flush the queues at the end of monitoring as to capture native interface files for the application being packaged. (I am told that as long as we are distributing to the same "architecture" this is OK. In this case "architecture" means within the Intel/amd x86/x64 family and not ARM. And I think that MSIX is similarly restricted anyway.)
