Background

When running a self-contained WPF app, it is observed that on startup in windows the exe makes calls to what looks like to load windows DLLs. However later on it attempts to load the same windows dll from the running directory of the exe. Example for one such DLL below (there are more, probably depending on includes).

Steps to repo

1. Create a new WPF app (I target .net 8, but also observed this in .net 6)
2. Create a new publish target, make it single file self contained
3. Publish the project
4. Use procmon to observe the dll it searches for

Expected behavior: for critical window DLLs it should only be looking in c:\windows\system32 or other system directories
Actual behavior: it looks in the current working directory (or same directory?) as the executable.

Attempt to use things like SetDefaultDllDirectories via PInvoke does not work as the dlls are searched for before main or even static constructors are executed; suspect the dll's are being loaded at a lower level.

Ideas for fixes

• Have a way to really only search system32 (or other system dirs) for loading windows dlls.
• If not possible universally at least for single file deployment (maybe this behavior could extend to beyond windows dlls as well?)

Notes

• This behavior was not seen in a blank console app; did not test to see what would happen if I added references that may trigger such calls.
• In a non-single file scenario, I do see it searching for hostfxr.dll (and others including windows dlls like ntdll.dll) in both the exe dir and in the shared location. I am not sure if it is possible to restrict the searching of such dlls for framework or self contained (non-single file) deployment for dotnet dependencies.
• As such I understand it may be impossible (or not even desired) to restrict dll search paths too much, especially if it impacts how shared installs of dotnet works. (I would think such locations would be protected by default). Maybe if there was a way to control it as needed by the dev?
• I do realize certain files may be extracted and then referenced; ideally the search path should only target that directory.
• I understand this may not be fixed (or that there is a design reason for this behavior), but still would like to put this out here.