Exception when loading native dlls from the application path when using AssemblyDirectory and System32 as the DllImportSearchPath

[ThomasGoulet73]

Description

There seems to be an issue when loading a native dll in the application path that depends on a native dll also in the application path when using DllImportSearchPath.AssemblyDirectory | DllImportSearchPath.System32 as the search path. When both of those scenario occurs, it'll throw an exception that the dll could not be loaded. This issue is not reproducible when using only DllImportSearchPath.AssemblyDirectory or if a native dll does not have a dependency on another native dll in the application path. This also doesn't seem to affect native dlls shipped in a runtime pack because the .Net host seems to include a custom search path for the runtime packs.

This is a bug I found while investigating a problem when running WPF unit tests, see #10304 (comment) for more info. I'm not sure if it's the expected behavior, a bug or if I simply misunderstood the bug in WPF.

/cc @dipeshmsft

Reproduction Steps

1. Clone https://github.com/[ThomasGoulet73/DllSearchPathRepro](https://github.com/ThomasGoulet73/DllSearchPathRepro)
2. Build TestLibrary1.
3. Build TestLibrary2.
4. Run ConsoleApp. It should exit without issue.
5. Open Program.cs in ConsoleApp.
6. Comment the line in Main with Test1WithoutSystem32
7. Uncomment the line in Main with Test1WithSystem32
8. Run ConsoleApp. It should exit with an exception that TestLibrary1.dll could not be loaded.

Expected behavior

Methods Test1WithoutSystem32 and Test1WithSystem32 should both succeed.

Actual behavior

Methods Test1WithoutSystem32 succeeds and Test1WithSystem32 fails.

Regression?

I tested using .Net 6 through .Net 9 and they all have the same behavior.

Known Workarounds

Change the DllImportSearchPath.

Impact

Not sure, I don't know how frequent this exact scenario occurs.

Configuration

.Net 9.0
Windows 11 x64
Don't know if it is specific to my configuration.

Other information

No response

[ThomasGoulet73]

I opened this in dotnet/WPF instead of dotnet/runtime by accident...

I'm closing this issue and opening another one in dotnet/runtime.

[miloush]

For those interested, moved to dotnet/runtime#111825