Self-Contained Single File trying to extract to the wrong User Temp folder

[Grimessa]

Description

An application is published as a single file and self contained.

When the user then runs the application and the app tries to extract to the "temp" folder it tries to extract to a non existent folder because it is using an invalid(shortened?) spelling of the username.

The following error is then reported in the Windows event log: Failure processing application bundle. Failed to commit extracted files to directory [C:\Users\DIANE~1.VVC\AppData\Local\Temp.net\AwesomeApp\MQWnC+cMPktvdEwnWlTK9IU_i_ivEME=]

It seems to be failing because this folder does not exist. It is trying to access a user folder DIANE~1.VVC but the actual userfolder should be diane.VVCOM So it should have tried to extract to: C:\Users\diane.VVCOM\AppData\Local\Temp.net\AwesomeApp\

If I manually create the folder C:\Users\DIANE~1.VVC\AppData\Local\Temp.net\AwesomeApp\MQWnC+cMPktvdEwnWlTK9IU_i_ivEME= Then the application does run. So it is definitely the problem.

Configuration

This issue occurred on Windows 11.

The application was created using the dotnet publish command with the following arguments -f net6.0 -c Release -r win-x64 -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true --self-contained true -p:PublishTrimmed=true

This was published using net6.0 and net5.0. Both gave the error.

Other information

Manually creating the folder it is looking for, does make the app run at least. It is however not desirable to have to do it this way.

[ManickaP]

@vitek-karas any ideas?

[vitek-karas]

There are several things weird here. But the basics is that we call GetTempPath https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-gettemppatha#remarks Can you please check if you redefine TMP or TEMP environment variables? Or what are their values.

[Grimessa]

Hi @vitek-karas, thanks for taking the time to look into this.

This is what I get

echo %TMP% C:\Users\DIANE\~1.VVC\AppData\Local\Temp echo %TEMP% C:\Users\DIANE~1.VVC\AppData\Local\Temp

So it seems the TEMP variables are pointing to this truncated version of the username. This is running on a client of ours and I am sure she did not redefine these variables.

The actual command prompt shows the correct name in the path name. C:\Users\diane.VVCOM> It is just those variables that are truncated.

I am not an expert, but was that format used for old MSDOS paths which could not exceed a certain length? Because it seems to treat it like a file by truncating the part in front of the '.' to 7 characters and truncating the part after the '.' to 3 characters as if it is an extension.

Does this mean it is a Windows issue, that Windows defined these variables incorrectly?

[vitek-karas]

You're correct this is the 16bit compat layer in Windows (for DOS) where it tries to make code written to expect 8 char long file names work on modern file systems. I don't expect Windows to set this, but probably some other software installer which needed the 8.3 file name format - but honestly I'm just guessing.

If the env. variable can't be fixed, you can set https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-environment-variables#dotnet_bundle_extract_base_dir instead which will take priority and the single-file will use that over the system's temp path.

[Grimessa]

Thank you very much for the help.

I will use DOTNET_BUNDLE_EXTRACT_BASE_DIR to set the correct path for cases where the self extraction fails.

It seems then that this is not a dotnet issue, and DOTNET_BUNDLE_EXTRACT_BASE_DIR is a good solve to get it working if TMP and TEMP are in the 8.3 format.

I will close this issue.