Slowness on first run of a self-contained WinForms exe

[snickler]

Description

The first run of a self-packaged WinForms exe results in 5 second delay before the form window presents itself to the screen. Initially I was filing this solely based on running .NET 5 Preview 6 on ARM64, but this also affects .NET Core the 3.1.3 SDK on x64.

On x64

mkdir winformsx64 && cd winformsx64 && dotnet new winforms
dotnet publish -r win-x64 /p:PublishSingleFile=true
cd bin\Debug\netcoreapp3.1\win-x64\publish
winformsx64.exe

On ARM64

mkdir winformsarm64 && cd winformsarm64 && dotnet new winforms
dotnet publish -r win-arm64 /p:PublishSingleFile=true
cd bin\Debug\net5.0\win-arm64\publish
winformsarm64.exe

Running both of these on their individual supported platforms will result in at least a 5 second delay before the form displays.

This behavior seems to also be impacted when extra NuGet packages are added. I tested this by throwing Microsoft.PowerShell.SDK version 7.0.1 into the projects: dotnet add package Microsoft.PowerShell.SDK, clearing the bin folder and then republishing the executable. I noticed the first run time jump from 5 seconds to around 12-15 seconds.

Configuration

x64

OS: Windows 10 19631.1
SDK: .NET Core SDK 3.1.300
Host: 3.1.4

ARM64

OS: Windows 10 19631.1
SDK: .NET SDK 5.0.100-preview.6.20276.4
Host: 5.0.0-preview.6.20271.10

Regression?

Data

I had no easy way of tracking the timing from when I pressed enter on the keyboard and when the form appeared, so I used Process Explorer to look at the timing of certain threads. The time lined up with my counting.

Barebones WinForms App first loading

When Form was presented to the screen

Barebones WinForms App with Microsoft.PowerShell.SDK NuGet package - first loading

When Form was presented to the screen

Analysis

The self-published executables extract the bundled framework to %LOCALAPPDATA%\Temp\.net\{nameofexe}\{somehashofcharacters}\ on first run, or rebuilding with changes. Subsequent runs load fast, since it reads the dlls from the temp directory. Deleting the directory will cause those framework files to be re-extracted and will re-create the directory along with the delay experienced on a first run. This process seems to be directly involved with contributing to the slow loading times.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @swaroop-sridhar
Notify danmosemsft if you want to be subscribed.

[snickler]

Linking to #36590

[swaroop-sridhar]

@snickler single-file apps currently execute by self-extracting the bundled contents to a temp-folder on first-run as explained in this document. The extracted files are reused on subsequent runs, this improving the startup times. The first run is also slowed down by antivirus checks. So, the slowness on first run is expected.

In .net 5 (upcoming previews), managed DLLs will be processed directly from the bundle without need for extraction (please see #32822) which will help ameliorate the problem.