How to get the extraction dir for single file bundle at runtime?

[wegylexy]

Is there an easy way to get the bundle ID from the bundle manifest? See also #43010

For WPF single file bundle with IncludeNativeLibrariesForSelfExtract true, the following code works.

[DllImport("kernel32", SetLastError = true, CharSet = CharSet.Unicode)]
static extern nint GetModuleHandle([MarshalAs(UnmanagedType.LPWStr)] string moduleName);

[DllImport("kernel32", SetLastError = true, CharSet = CharSet.Unicode)]
static extern uint GetModuleFileName([In] nint module, [Out] StringBuilder fileName, [In] uint size);

StringBuilder sb = new(255);
_ = GetModuleFileName(GetModuleHandle("PresentationNative_cor3.dll"), sb, (uint)sb.Capacity);
Path.GetDirectoryName(sb.ToString())!;

[TXAE]

I'm not sure whether I might have misunderstood the title (this was the first result when I googled "determine directory where single file extracts to c#"), but Path.GetDirectoryName(sb.ToString())!; gives me
"C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App\6.0.5"
which is NOT the
"C:\Users\TXAE\AppData\Local\Temp.net\my program\fancy URI"
I was looking for (where my single file bundle extracts to)

[vitek-karas]

This approach only worked in 3.1 where everything was extracted. In 6 all of the managed code is loaded from the exe itself (from memory effectively) and is never written to disk. So the extraction only happens if you ask for it (it's off by default completely) and typically only for native libraries.

[TXAE]

I'm using .NET 6 and when I launch my self-contained single file (exe) I find all the stuff at "C:\Users\TXAE\AppData\Local\Temp\ .net\my program\fancy URI"
that the publish folder would otherwise contain (without single-file option ticked). So stuff is extracted to disc and I'm not sure which default settings I've changed for that to happen.

I found out that AppDomain.CurrentDomain.BaseDirectory helps, but I'm not going to use that AppData\Local\Temp folder for my application.

[vitek-karas]

Thanks for the reply. The default in .NET 6 is to only bundle managed code (which will not be extracted) and leave everything else next to the exe. To bundle more you need to either set

• IncludeNativeLibrariesForSelfExtract - only bundles native libraries, but then you typically don't need to know where they are extracted to as runtime will wire it up correctly
• IncludeAllContentForSelfExtract - will bundle everything, including random data files. In this setup the app is completely extracted to disk (even managed code) - this is effectively 3.1 backward compat mode.

Note that the defaults are based on the TFM of the app you're building. So even if you're using .NET 6 SDK if the app is targeting netcoreapp3.1` it will get the 3.1 behavior.

[vitek-karas]

This is basically exactly #43010. I would be very curious why do you need to know that location.
The runtime should wire everything up for the typical case where you're bundling just native libraries (that is DllImport should find the libraries there). There should be basically no other files there.
If you're using the 3.1 compat mode where everything is extracted then the BaseDirectory should still work.

[wegylexy]

I need to load the OpenSSL build of msquic on Windows 10 and the faster Schannel build on Windows 11. The runtime only wires up x86, x64, arm64 properly without a way to target Windows versions or whether built-in TLS 1.3 support is available for QUIC.

[vitek-karas]

I think NativeLibrary.Load will use the internal mechanisms to lookup the location. I think it uses the NATIVE_DLL_SEARCH_DIRECTORIES runtime property passed by the host - you could use that as well AppContext.GetData("NATIVE_DLL_SEARCH_DIRECTORIES") - not exactly a public API, but it's unlikely to change anytime soon.

@jkoritzinsky does NativeLibrary.Load follow the same library lookup algorithm as [DllImport] ? (Would be nice to mention this in the docs: https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.nativelibrary.load?view=net-6.0)

[jkoritzinsky]

The overload that takes an Assembly and DllImportSearchPath follows the same rules as a DllImport in that assembly with the provided search path. The overload that just takes a string directly maps to LoadLibrary/dlopen.

[vitek-karas]

Thanks @jkoritzinsky - in that case calling the NativeLibrary.Load which takes Assembly parameter should let you load the native library without knowing where it's extracted to - by just passing a simple name.

[TomEdwardsEnscape]

The extraction path is provided by AppContext.BaseDirectory.

I've found that value to be the same as the one that can be extracted from from NATIVE_DLL_SEARCH_DIRECTORIES, as was suggested above by @vitek-karas.

[Frostchi]

This does not seem to be correct any longer in .NET9 at least. I tried AppContext.BaseDirectory and it returned the location of the Single File EXE and not the self-extract directory.

There really should be a mechanism to get this path for advanced use cases.