Core: The application to execute does not exist - Error when starting app

Created on 18 Nov 2019 · 12Comments · Source: dotnet/core

Application would not start, event viewer shows "Application to execute does not exist" error

Application Type: Winform application is published as single file, self-contained binary using .net core 3.0 SDK (RTM version as of date)

All of a sudden the application would not start, looking at event viewer, it seems it is extracting the binary to a temporary folder and errors out with "The application to execute does not exist c:users\\AppData\LocalTemp.net\ApplicationName\ShortGUID\App.dll"

Resolution

Deleting the ShortGUID fixes the issue and app could start again. I see the same issue on RedHat 7 once (with a console app) but thought was one off or something, but I see this on windows now too. Very frustrating cause the same app worked earlier but suddenly broken out of nowhere.

Source

rohitisinhk

Most helpful comment

Having the same issue on net core 3.1

Hphipps on 6 May 2020

👍4

All 12 comments

Can you provide a sample solution which reproduces the problem?

scalablecory on 18 Nov 2019

@swaroop-sridhar

jeffschwMSFT on 18 Nov 2019

Sorry I can't reproduce this issue at will, I deployed the app in production two weeks ago, it works well for our internal users, but today one user could not run the same app all of a sudden, since I didn't see any logs generated I realized the app is not even initializing (we print info on app start).

Digging into event viewer I see it has to do with some extraction of single file assembly deployment. Deleting the folder helped

rohitisinhk on 18 Nov 2019

@rohitisinhk, I understand the problem.

In the current release, there's one solution to mitigate it: The location where the bundle contents are extracted is configurable via the DOTNET_BUNDLE_EXTRACT_BASE_DIR environment variable. So, it can be set to any user directory that's not cleaned up automatically.

Currently, the DOTNET_BUNDLE_EXTRACT_BASE_DIR must be set in the client environment, and not within the app (because it inherently depends on the runtime file structure). https://github.com/dotnet/core-setup/issues/8865 tracks the issue of setting the extraction location at compile time.

@rohitisinhk Does this help you circumvent the problem? Subsequent implementation of single-file solution will reduce/eliminate the reliance on temporary extraction directories.